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Hiding in Piain Sight... 

Oome of the most interesting, challenging 
programming is being done outside the 
prevailing paradigms. It's been this way for 
years, and some companies regard its speed, 

COMPACTNESS, EFFICIENCY and VERSATHJIY 

as their private trade-secret weapon. 

It has penetrated most of the Fortune 500, 
it's a veteran in aerospace, it's in SPARC 
WORKSTATIONS, and it's how "plug and play" 
is implemented in the newest Power PCs. 
In fact, it's lurking around a lot of comers. 

it's Forth. Surprised? Call now to sub- 
scribe* and learn more about today's Forth. 

Forth Dimensions 
510-89-FORTH Fax: 510-535-1295 

*Ask for your free copy of "10 ^ys to Simplify Programming" 
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Editor's Column 



And in this issue. . . 



We have Win95 in the house now. My wife's laptop for 
work came with it and she's required to use it. The only 
crashes she's had involve the online connection she uses for 
work. Otherwise there have been no 'problems' but... 

Looking at Win95 on her computer has verified my suspi- 
cions about it. The primary purpose of Win95 was to boost 
lagging sales by Microsoft and the other major PC software 
and hardware manufacturers. They made enough changes 
to make sure that your old software wouldn't run as well as 
their new software. They also made many little changes in 
the names of things so that finding a function that you used 
in Win3.1 or DOS sometimes becomes a little challenging. 

Another thing is the hardware. Win95 expects certain things 
from the hardware and can be uncooperative when it doesn't 
find them. Win95 is 'designed' to be smarter than the aver- 
age consumer that buys it (and I wouldn't be surprised if it 
is). It was not intended to cooperate with the minority of us 
who think we can set things up ourselves. My recommen- 
dation is that if you really need Win95, get a new machine 
that is intended to run it (and save your old machines for 
your old software). It can minimize the problems you run 
into. 

I'm not against Windows or any other particular software or 
hardware. The TCJ 'philosophy' is that you use products for 
what they're good for. I use Win3.1 programs to publish 
TCJ. No DOS program that I know of will do the page lay- 
out that I need. On the other hand, I always make a note of 
the things that people have done that seem to benefit them 
more than me. I've paid (a lot) for the software I use and I 
don't particularly like the idea that I should pay again to do 
the same thing because someone else needs to sell a new 
product. 

With the exception of Desk-top publishing and graphics, 
every program I use to make money runs under DOS. Well, 
actually, SLR's Z80ASM runs under CP/M and it still makes 
me some money. Obviously, most of the 'big' companies 
aren't making any money from me at the moment. I'm sure 
they'll 'get me' eventually. When I just gotta have the latest 
upgrade, it will be a Win95 version and I'll have to break 
down and buy a Win95 machine. Then I'll have every thing 
from my first CP/M machine (a Bigboard 1) to a Pentium 
here in my office. All I have to do is find a place to put all 
of them. 

Dave Baldwin, 

Editor/Publisher 



PS: If you find yourself dependent, like I am, on older soft- 
ware. Make Sure You Have Backup copies! ! Many compa- 
nies are out of business and many others won't support their 
older software. 



We lead off with B/P Bios by Hal Bowers and Cam Cotrill. 
They're still working on it and refining it. Next is my ar- 
ticle on the PC serial ports in ASM and C. There have 
been a lot of requests for working code for the PC serial 
ports so here are three small terminal programs, two in 
ASM86 and one in C. This is one of those 'easy' things. 
One of my customers recently thanked me for doing a cus- 
tom version for him in only two weeks. I told him it wasn't 
hard, all it took was ten years preparation. 



Allison Parent, a new author for TCJ but an old hand at 
micros and CP/M, writes about adapting PC hard disk cards 
to other systems in Cheap Hard Disk Controller. Part 3 of 
the continuing saga of Simplex III is here also along with 
Rick Rodman's Real Computing column. 



Another new author, Andre Fachat, presents his High Speed 
Serial for the 65xx, Add a 16550 to a 6502. He shows 
what it takes to adapt a chip to a system it wasn't designed 
for. I'm not sure what the 8250/16550 were designed for, 
but he has it working with his Commodore C64. 



Ron Anderson continues with Small System Support and 
Bill Kibler with The Computer Corner. Helmut Jungkunz 
is back with the European Beat this issue with an article 
about coercing dBase to cooperate with the ZCPR TCAP. 



Next Time.. 



Part two of B/P BIOS is in the next issue along with Ron 
Anderson's PC serial and parallel port test programs in C. 
There will be more PC programming articles along with em- 
bedded hardware and software in the issues to come. 

Don Jhindra, author of The Little Big LAN, is working on 
some networking articles but I don't know when they will be 
ready. He's done some fascinating things with LBL. In 
addition to standard network cards (Ethernet and Arcnet), 
LBL has built-in support for both serial and parallel ports. 
I bought a copy but I haven't had time to install it. Since 
Don also provides programming support, it looks like I 
should be able to make LBL talk to just about anything. 
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About The 'Net 



by Ted Deppner 



New Column 
Internet Myths 



The Internet: Myth No More 

The Internet is the latest storehouse of myths in people's 
minds. Some myths are heated, (pornography galore!), some 
are bad (those nasty Internet Police), and the bare truth about 
the Internet gets little air time. Myths usually talk about 
what the Internet is, completely ignoring what it isn't. We'll 
talk about both and give you a more complete view of the 
Internet as it is, and what it may become. 

The Internet is above all else a reflection of society. 
There is something for everyone online. There are match- 
cover collectors, TTL chip directories, model railroad fanat- 
ics, crocheters and knitters, libraries, state and federal agen- 
cies, and so on. (and TCJ, of course) You can find the lat- 
est in golf clubs, USR's X2 upgrade, or just the drivers for 
your sound card. And yes, you can find pornography, politi- 
cal propaganda, and the latest in home built explosives. This 
is a reflection of society, remember? 

Myth #1: Pornography and other stuff. Just like in the 
physical world around you, you make the choices about 
where you go and how you spend your time. You make the 
choices, they aren't forced on you. If you don't like the adult 
book store, you don't go in. You can just as easily choose 
the local electronics hut of retired hardware. It's the same 
on the Internet: you go where your interest are, and stay away 
from those "other" areas. To each his own. 

Myth #2: The Internet Police and Big Brother. Those 
guys sure do get around. Hah. The Internet is a large col- 
lection of cooperating but separate entities — there is no cen- 
tralized anything. As such, there is no central repository of 
information, no government affiliation or governmental 
control, and no police. This doesn't mean you can do any- 
thing you want and "get away with it". While there is no 
central control and record keeping, records are kept. 

A record of where you have been, what file you have 
downloaded, or where you sent email to is kept, but the con- 
tents of these items is not. Somewhere deep in your service 
provider's logs it says "me@here.com" sent an email to 
"him@there.com", but what the message said is not re- 
corded. There's a log entry that someone at there.com viewed 
my home page, but who that actually was isn't listed. 

Time, date and origination are the extent that is kept. 
Your name, address, or anything identifying you as "you" 
are not kept, unless you choose to provide that information. 
However, armed with time, date, origination, and a court 
order, your Internet service provider could easily determine 
who was there at that time. 

Myth #3: Etiquette and morals. Moral ineptitude is 
frowned on by the Internet community. If you send out the 
latest Make Money Fast file, expect lots of email calling you 
names. Email 10,000 people your latest sales flier out of the 
blue and expect your service provider to shut your account 
off. 

Illegal activity is always illegal, and stuff you couldn't 
do in your local communities you can't reasonably expect to 



do online either. If you have questions, contact your service 
provider, they should be more than happy to help you. 

Myth #4: The Internet has everything. Well, yes it 
does, Uiough it may not be exactly what you wanted. Any- 
thing that is freely available in the world is online. Works 
by Shakespeare, Foe, and Doyle, sports scores, stock reports, 
and so forth. You can find plenty of home built circuit dia- 
grams for all sorts of devices, but you probably won't find 
the latest schematic for your TV online. You won't find the 
latest book by Stephen King online, nor up to the minute 
stock information. You can find reviews of King's latest 
book, and you can get your stock information delayed by 
fifteen minutes. Of course, if you want to pay to get King's 
book you can, likewise you can get your stocks up to the 
minute if you subscribe to that service. 

Myth #5: Buying the Unknown. Everywhere you go 
in society, you have offers to purchase things: Books, maga- 
zines, new computers, the latest Microsoft collection of bugs, 
and new "must have" widgets. In the real world, you have 
to pull out the flat wallet, peek through it, and put forth 
green or plastic. So also goes the Internet. In general, ev- 
erything online is free. If it is not free, it will tell you so, 
and make you give your credit card numbers and name be- 
fore letting you on. You won't just stumble into some pay 
area and all unknowing start racking up charges. Once 
again, it's your choice. Good companies will provide a fi^ee 
sample of what they offer, so you can get a taste. 

Myth #6: They'll steal my Credit Cards! Recent ver- 
sions of Internet browsers can encrypt what you're sending, 
and you can use security programs like PGP (Pretty Good 
Privacy) for email. Getting your numbers would be a needle 
in haystack kind of problem in the first place, so add to that 
encryption of one sort or another, and the fact that there are 
much easier targets for thieves, and it's not a huge threat. 
Obviously you shouldn't say "hey evetybody here's my credit 
card", but then you wouldn't do that in the real world either. 

The Internet is a vast and wonderfiil place. It reflects the 
society of the world around us, and each of us can person- 
ally benefit from what the Internet offers. We can each have 
an effect on what the Internet is, through our participation. 
There are email discussion groups and USENET news 
groups with topics that range from iguana care to how to 
repair TVs. You can even put your own web pages online, 
detailing to the world how to make the Mr. Spiffy Widget, 
or simply stating how you made your networked coffee ma- 
chine. So step forth without fear and newly armed with the 
truth about these six common Internet myths. 

Happy Netting! ===== 

— Ted Deppner, ted@psyber.com, http://www.psyber.com 

Ted takes care of the technical stuff at Psybenvare where 
the TCJ Web pages are located. 
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Letters and News 
All Readers 



READER to READER 



MINI Articles 



Send your letters for Reader to 
Reader to: 

The Computer Journal 

P.O. Box 3900 

Citrus Heights. CA 95611-3900 

From: Christopher Burian 
<cburian@n . mit.edu> 

Subject: 8051 Startup code in TCJ 
#78 

Thanks for this great article. It's the 
best, maybe only, article I've seen yet 
that implements working interrupt- 
driven serial and circular queues. 

I'm astounded by all the sample code 
out there, even sophisticated-looking 
monitors, that use queueless polling to 
send and receive. It's either that or 
generic pascal-like junk found in next- 
to-useless textbooks. 

Luckily, I had a college class on 8088 
assy programming which included a 
unit on circular queues, interrupts, pro- 
gramming the 8230 uart, etc., but most 
people don't get that kind of class. I 
guess it's considered unorthodox and 
out of the mainstream to actually teach 
students how to write real programs 
that run on genuine CPUs. Entirely too 
much programming at my U. was taught 
in virtual languages which were com- 
piled and simulated on virtual comput- 
ers existing only in the perverse imagi- 
nations of CS professors. So I think 
lots of people are going to find your 
8051 introductory article really useful, 
as I have. 

Despite my previous exposiue to queues, 
your sample program is a great help to 
me in simplifying my own code. 

I wish you'd had a little more time/ 
space to delve into the problem you 
discovered wrt interrupt code on NMOS 



vs. CMOS chips, and perhaps given an 
example of code ordering which you 
found not to work, just in case someone 
decided to make modifications to your 
code. Unlike the hell's protective fea- 
ture (write within the first 64 clocks 
only) the problem you've discovered 
sounds more like a bug than a feature. 

On my current project, I'm again rein- 
venting the wheel, making a monitor/ 
hex-downloader, because just like lots 
of other guys, I think I can do it a tiny 
bit better. One of the gimmicks I want 
to include and haven't seen anywhere 
is intelligent handling of BREAKs sent 
from the host. Another is use of hand- 
shaking when queues fill up, to handle 
delays when programming FLASH dur- 
ing a hexfile download, for instance. 

I have a couple questions about your 
QUE_SND routine. Why isn't a CLR 
C required before the SUBB? And why 
use SUBB instead of CJNE? 

Thanks, and keep up the good work. 

Eagerly waiting for #79, 

Chris Burian 

I'm glad you liked the 8051 article. 
TCJ if 77 had an article with similar 
code for the Z80-SIO and this issue has 
my article on the PC serial ports. 

I never did find what the original prob- 
lem was. I'm sure it 's a 'bug ' of some 
sort. The Intel 8051 experts couldn 't 
figure it out, may not have been inter- 
ested. The original program I started 
out with was SKELETON. ASM from the 
Phillips BBS and it didn 't work on the 
CMOS 80C31. I don 't know whether it 
worked on the NMOS version. I got a 
copy of one of the standard, polling 
monitors from a friend and it worked 
on all versions of the chips. That veri- 
fied to me that the chips were working 
and that I Just had to do something 



different with my program. I went back 
to the books to see what might be de- 
pendent on the sequence and this pro- 
gram is where I ended up. 

About the QUESND routine, the 'CLR 
C probably should have been in there. 
After looking at the program, it 's prob- 
ably just an accident that it works with- 
out it. 'CJNE ' tests for the wrong thing 
in this case (NE). I needed to know if it 
was equal to lOh. A TXJCNT of 
means that all bytes have been sent. 1 
to lOh means that there are bytes to be 
sent in the fifo and lOh is the max the 
fifo can hold. 

Dave Baldwin, Editor 



From: "Jeffrey A. Weiner" 
<j_weiner@juno.com> 

Subject: XT's and kindred folk 

Kudos on Issue No. 79! Well worth the 
boost we all gave you. 

I also wanted to note that its a good 
thing that TCJ is covering XT-class 
machines. Case in point: I rescued 3 
ALR Barrister XT system units from 
the dumpster of the building I work in. 
ALR had scant info on the motherboard 
switches, and nothing on the unique 
combination controller card that was in 
the beasties; connections for 2 pairs of 
floppy drives, serial and parallel ports, 
clock/calendar, and a mysterious 50- 
pin header marked "fflGH DENSITY 
DRIVES". I'm hopeful that a someone 
who reads/ writes for TCJ will e-mail 
me some info on this card so's I can 
take advantage of its features. 

And those kindred spirits? Well, one 
thing I'd like to see is some articles 
about doing something useful and/or 
different with a DEC Rainbow. I have a 
few (!) of them on the premises, and 
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since the International Rainbow Users 
Group has hit the bit-bucket, it would 
be nice to see some guidance from some 
more technically-adept Rainbow 
afficianados. 

Keep 'em flying... 

Jeff Weiner Chicago, IL 



From: Ron Anderson 

<rwilande@concentric. net> 
Subject: Hard Drives 

Dave, 

Last July my Conner 830 Mbyte hard 
drive crashed. It was eleven months 
old. Knowing that it would take a while 
to get a warranty repair, and having a 
use for that drive in another system, I 
bought a new Western Digital 1070 
Mbyte drive as a replacement. 

Conner had just been bought by Seagate, 
and partly due to transposition of two 
digits in the Return Authorization num- 
ber (my error, not theirs), it took about 
six weeks to get the replacement drive 
back. Either they sent a new drive or 
they replaced the tag on it, because the 
new one said Seagate on it. 

Shortly after that, I went to "defrag" 
the new WD drive and an error mes- 
sage appeared saying that parts of the 
disk were not accessible. I ran 
"scandisk" on the drive and it found 
about 1 megabyte of bad sectors all in 
the last 150 or so tracks of the 2488 on 
the drive. I decided to watch the drive 
carefully and to call WD if more bad 
sectors were mapped out later. Last 
month the drive failed a defrag session 
again and I found that another 400K of 
sectors had gone bad. 

I called WD and they asked me to down- 
load a diagnostic from their web site 
and run it on the drive, and call back to 
report the result. The next day I phoned 
them and they said the drive was bad 
enough so they would replace it under 
wananty. With my credit card number 
as collateral, they sent me a new drive 
and I transferred a large number of 
files after reinstalling DOS and Win- 
dows 3.1 on the new drive. I ran 
scandisk again and before I had all the 
software installed, I noted some bad 
sectors had to be mapped out, again all 
at the very end of the drive. 

About at that time, my replacement 
Seagate drive quit completely. It 



sounded like the head servo had gone 
crazy, and couldn't read data from the 
drive. I called Seagate and after ten 
minutes of tone button pushing on their 
"automated service line" the computer 
gave up and informed me that there 
was a problem and transferred me to a 
real live person, who was most helpfiil, 
agreed that the drive was under war- 
ranty, and gave me a return authoriza- 
tion number. This time I was careful to 
see that I got it right, and I have sent 
both drives back to their respective 
manufacturers. 

The next day, I was talking to a friend 
who is experiencing the same difficul- 
ties with a Western Digital drive. He 
reported that about 6 megabytes of sec- 
tors had been mapped out, and that the 
bad list continues to grow. He has run 
the WD diagnostic and was planning to 
call for authorization to return the drive 
last time I talked to him. 

Could it be that the manufacturers in 
their race to cram the most data in the 
least hardware have pushed the tech- 
nology beyond the limit of reliability? 
I've used Western Digital drives for 
years, and in fact have a couple still 
running that had never had a problem 
(an old 100 Mbyte drive and a 170 
Mbyte). 

I've ordered a "refiirbished" 650 Mbyte 
drive to have around as a spare. Maybe 
this one was before the technology got 
pushed into the area of unreliability. 
We'll see what happens with the 
Seagate. 

I must add that I was treated very cour- 
teously by both Seagate and Western 
Digital's service people. The wait was 
minimal (a few minutes) in both cases. 

Ron Anderson 



From: Ken Deboy 

Dear Bill, 

I figure that if I'm going to criticize 
Windows95 and Microsoft, I should ex- 
plain some of the problems I've had 
with Win95 and in dealing with 
Microsoft, so here goes: 

1. The pamphlet (no way it could be 
called a "manual") doesn't explain how 
to do anything . For example, I had to 
call a 3rd-party software vendor to find 
out how to over-write the MBR so I 
could install System Commander 



(Win95 doesn't normally allow this to 
be done). Microsoft was no help be- 
cause they won't provide tech support 
to someone who obtains Win95 pre- 
installed on their computer. (I could 
really get into what I think about a 
software company that won't support 
their own damn OS, but I won't.) 

2. It sometimes locks up on me, with no 
way to recover except turning off the 
computer. Of course, there is a dire 
warning in the pamphlet to never do 
this, but what else is there to do when 
even <CTRL-ALT-DEL> doesn't work? 
Never had this problem under Win3.1 
(or Linux or OS/2). This isn't a "rare" 
occurrence, either... at least 3 times a 
week, sometimes even twice in one day. 

3. It won't let me delete DLLs from 
...AVINDOWS/SYSTEMeven if they're 
not write-protected. It also won't let 
install programs over-write them if one 
tries to install a DLL that is already 
there. I have to drop back to DOS to 
delete the file, which is fine, since I 
know how to do it (no thanks to 
Microsoft), but what about the poor soul 
who has a Win95 box as their first 
computer? 

There are other minor frustrations with 
Win95, but these are the major prob- 
lems I have with it. Sorry for the rant, 
but I don't feel right criticizing a prod- 
uct without explaining why I feel the 
way I do. I hope Caldera wins their 
lawsuit against Microsoft, but I'm not 
betting on it. I feel the only way to 
make sure MS doesn't become a mo- 
nopoly is to make sure that other OS's 
are economically viable. I have OS/2 
on one computer, and soon I'll have it 
on both my computers. When I need a 
program, I try to find a version that 
will run under OS/2 or Linux. If I need 
a program that is only available under 
Win95, 1 always make sure to write to 
the software company and tell them I'd 
be interested in purchasing a version of 
the program to run under OS/2 or Linux. 
Maybe if enough people did that, MS 
would lose the strangle-hold they have 
on the PC software industry. Well, at 
least I can dream... 



With best wishes. 
Ken Deboy 
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From: Steve Johnson 

Dave: 

Enclosed is my early renewal check for 
TCJ. 

Detailed comments about the magazine 
should wait for a future message, but 
you should know that I always read the 
magazine with a day or two of arrival 
and I continue to use the complete set 
in my study. I like the practical, prob- 
lem solving approach authors take and 
the mix of diverse hardware, operating 
systems and languages covered. Even 
when I'm unlikely to work with a par- 
ticular combination of hardware and 
software, I enjoy the articles and learn 
of practical value. 

Subjects of particular interest to me are 
small scale networking and operating 
systems including Linux and Forth. CP/ 
M remains of interest and I follow 
'comp.os.cpm' closely. Like many other 
readers, I run MYZ80 instead of nurs- 
ing my (diminished) accumulation of 
aging Osbomes and their many acces- 
sories. During my last binge of old 
equipment accumulation, I picked up a 
dual set of Siemens 8 inch drives which 
interface to an Osborne Executive with 
quad density internal drives and dual 
external hard disks. It pains me to 
admit it, but the Osbornes are less ro- 
bust than the Kaypros. 

Rick Rodman is one of my favorite TCJ 
contributors. My at-home computing 
network is much less elaborate that the 
Kettlepond Computing facility, which 
serves as inspiration. I believe my next 
networking step will be to extend the 
thinnet from the second floor to my 
basement workshop & home brewery 
(well I do have other interests besides 
computers). That will be a natural time 
to get involved with home monitoring 
and control. 

Enough comment, time to write a check. 



Signed: Steve Johnson 



From: Rick Bromagen 
To: Dave Baldwin 



Hi Dave! 

I just received the last issue of my sub- 
scription to TCJ (#79), and that re- 



minded me there was something I have 
been intending to do for several months 
now. It's time to renew my subscrip- 
tion! Let's have 2 more years please. 

I had been trying to figure out how to 
add an IDE interface to my Z80 CP/M 
system for several years. Then TCJ 
published the articles from Tilmann 
Reh. That was great work! We all owe 
people like Tilmann a big thank you. 
Those that have the time, knowledge, 
and are willing to share their efforts 
with everyone else have my respect. 

I assume there are at least a few who 
have built the GIDE interface by now, 
and have done some tinkering with 
BIOS driver software. Of course we all 
seem to have different systems and 
BIOS's, so sharing source code is not 
simple. I am planning to put a GIDE 
on my Eagle II mother board. It al- 
ready has a SASI (early SCSI interface) 
drive, but I like the challenge of put- 
ting a much faster and bigger drive on 
this system. 

That reminds me, I would like to hear 
in TCJ about different ways to add large 
hard drives to CP/M. By that I mean 
how to have a 40 or 80 megabyte CP/M 
drive "partitioned", and how the BIOS 
tables describing it look. I think Ampro 
and several other had done this. Is 
there a public domain description or 
code sample for this? 

That TCJ centerfold about the PI 12 
board looks very interesting to me. How 
can I get one of these? When will TCJ 
offer a group buy? I am busy thinking 
up several projects I could "embed" this 
and a drive into. How about an embed- 
ded household controller with floppy 
(ala Circuit Cellar Ink HCS II), or a 
portable CP/M system? I remember 
David McGlone of the Z-Letter once 
mentioned that there was a computer 
built in a small, flat portable case, with 
maybe an LCD screen. Maybe I will 
try pulling the Z80, and putting the 
PI 12 board with a 3.5" drive. How 
about a 2.5" hard drive as well? Of 
course, battery power will need some 
thought. There are a lot of high power 
replacement batteries for laptops avail- 
able now that could be small and light 
weight enough. It would be fun on my 
next long airplane trip, to pull out a 
CP/M laptop, play some games, or even 
do some writing. 



Disconnect 

Dogbone McGillicutty groaned when 
he heard the 'snap' that told him his 
network fiber had popped out of the 
wall. He was just trying to move his 
workstation a little bit to make some 
room. He started imagining the parade 
of people he'd be seeing soon. First 
would come the Nettertons network se- 
curity people to see what had happened 
to 'their' connection. Of course, none 
of them could repair the break, but they 
could cite you for 'Illegal Disconnect', 
section blah-blah-blah of the Network 
Code. They would tell you to get it 
repaired right away. If they were in a 
good mood, they'd call repair for you 
since, of course, you couldn't because 
you just broke your network connec- 
tion. 



The last time he had called repair was 
from a friends terminal. First, they 
asked why he was calling since the sys- 
tem was obviously operating since he 
was able to call them. Then they wanted 
to know why he was using someone 
else's station and did he have permis- 
sion to do so. After identifying him- 
self, his employer, and his station and 
waiting for them to verify that he wasn't 
home using his station, they finally 
agreed to come repair it although they 
warned him that he would be charged 
double if it was a UIP (User Induced 
Problem). 



After (or maybe even before) the repair 
droids showed up would come the 
HW2020 (Home&Work) people to find 
out why he wasn't using their 
systemware for his each and every need. 
And somewhere in one of those groups 
would be a Copper-Checker to make 
sure he wasn't one of those that had 
found out how to blackbox the old cop- 
per network and avoid his responsibili- 
ties (and payments). And after all of 
those people were done, he'd have to 
go through a reconnect session and 
verify his ID and his accounts and all 
of his passwords which would take a 
half a day. Can't have any illegals on 
the Net. 
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Banked/Portable I/O 
System (B/P Bios) Pt I 

by Harold F. Bower and Cameron W. Cotrill 



Special Feature 
Z80/1 80 Systems 
Advanced BIOS 



For the past several years we have attempted to address 
some of what we consider to be fiindamental problems in 
the 8-bit Z80/Z180/HD64180 system software arena. Our 
first effort, ZSDOS, was directed toward what we believed 
to be architectural weaknesses in CP/M and its clones in 
the late 1980s. Such weaknesses included; inefficient code, 
inconsistent implementations of some DOS functions, nu- 
merous different and incompatible file Date/Time Stamp- 
ing methods, and just plain errors (remember Function 37?). 
Now in the 1990s, even more effort is needed to correct the 
proliferation of systems designed on faulty (or at least weak) 
architectures, and to provide a logical and consistent path 
to increase the functionality of our systems. 

To understand our concerns in this area, let us review 
the way in which CP/M 2.2, as modified by the Z-System, 
uses available memory. For standard CP/M and compat- 
ible systems, the only absolute memory addresses are con- 
tained in the Base Page which is the range of to lOOH. 
All addresses above this point are variable (within certain 
limits). User programs are normally run from the Tran- 
sient Program Area (TPA) which is the space from the top 
of the Base Page (lOOH) to the base of the Basic Disk Op- 
erating System (BDOS). Figure 1 depicts assigned areas 
pictorially along with some common elements assigned to 
each memory area. 



ENV, TCAP. lOP, FCP, RCP 

(~5K) 

Code + ALV, CSV, Sector Buffers 

{■-5.5K) 

CP/M 2.2, ZRDOS, ZSDOS1 

(3.5K) 

CCP, ZCPR3.X 

(2K) 



lOBYTE, Jmp WB, Jmp Dos 
FCB, Buffer 

Figure 1. Typical Z-System Memory Map 

The sizes depicted for the Z-System buffers is typical 
of many, and allows a certain functionality. It is sometimes 
necessary to delete some capabilities to add others, since 
every addition in this area pushes the other components 
lower, decreasing available TPA space. Likewise, any new 
features or more elaborate routines in the Bios decreases 
available TPA. 
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Z-System Buffers 
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There have been some attempts at ameliorating these 
difficulties, but none have directly addressed the entire prob- 
lem. One system in relatively widespread use is NZCOM. 
It allows a fairly easy method of changing systems "on the 
fly". The main drawback, however, is that to obtain large 
TPA, system features must be sacrificed by deleting or 
downsizing the resident Z-System segments 
(FCP,IOP,RCP,NDR,TCAP). To us, this method is only 
viable in systems which do not have extended memory ca- 
pabilities. With the ever-increasing use of systems based 
on the Hitachi 64180 and Zilog Z180, other solutions are 
more attractive and offer a larger TPA without sacrificing 
system capabilities. 

The final major factor contributing to shrinkage of TPA 
is the increasing commonality of large hard disk drives. 
Disk space is managed by a bit-mapped buffer (ALV) where 
each bit represents an allocation block of storage space. 
Typical allocation units are 2k for floppy diskettes and 4k 
for Hard Disk Partitions. Assuming 4k allocation blocks, a 
20 MB drive needs approximately 20000/4 = 5000 bits or 
625 bytes. With 80 to 100 MB drives being common these 
days (one B/P user reported that the smallest drive he could 
obtain was 850 MB!) you should see that several kilobytes 
are now required, further reducing available TPA space. 

The first requirement to place us on the road to more 
powerful systems is to overcome the 64k memory limit im- 
posed on direct access by the Z80 family of processors in a 
consistent and logical manner. Such a technique, generi- 
cally called memory banking, means that we can access more 
than 64k of memory for something more than simply a RAM 
disk. 

One of the first attempts to tackle the 64k memory bar- 
rier was Digital Research with CP/M Plus (aka CP/M3). 
While it banked both portions of the BIOS as well as the 
Basic Disk Operating System (BDOS) and included some 
usefiil additions to the BIOS, it was relatively incompatible 
with CP/M 2.2 in many key features. In addition, CP/M 
Plus made no provision for banking application code. The 
adoption of a CP/M 2.2 standard for the Z-System has served 
to widen the compatibility gap even further on the majority 
of our systems. 

There are some internal inconsistencies in the CP/M 3 
architecture as well which were never fully resolved. A 
prime case in point is the function to return Disk Free Space 
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(Function 46). The specification states that three bytes are 
returned reflecting the number of available 128-byte records 
on a disk. This equates to 2'^24 * 128 or 16,777,216 ♦ 128 
= 2,097,152 kB. While we know of no one who has actu- 
ally installed a single disk partition of more than 2 Gigabytes 
on a Z-System, it would create problems since CP/M Plus 
can handle disks up to eight times this size, but not cor- 
rectly report free space. Simply returning free space in terms 
of 128-byte records is inconsistent as well since disk space 
is allocated in blocks which have a minimum size of Ik, 
with 2k and 4k commonly used. This is only one example 
of several, and we do not consider it a viable system for 
future Z-System growth; although it is still being actively 
installed. 

Several manufacturers have attempted to bank portions 
of operating system software over the years, yet either locked 
the software into their hardware as Epson id with the QX- 
10, or made such changes as to limit portability of common 
tools as in the XLM-180. This latter system, while it used 
the Hitachi 64180 processor with its memory mapping ca- 
pabilities, required system tailoring of much of the com- 
mon Z-System software base. 

The release of MicroMint's SB-180 in the early 1980s 
marked a decision point in Z-System development. First, it 
retained all standard ZCPR3 definitions, it used a CP/M 2.2 
compatible BDOS, and it forced programmers to think more 
of portability and compatibility in system software. This 
was a major thrust in the development of XBIOS which 
placed the greatest possible amount of BIOS code in alter- 
nate memory locations outside of the primary 64k address 
space. Furthermore, capabilities to bank additional features 
(Resident System extensions, or RSXs) were widely sup- 
ported with DateStamper, DosDisk and others requiring no 
sacrifice in TPA to execute. Since its last upgrade, how- 
ever, several severe problems have come to light, among 
them are the inability to properly handle hard disk sizes 
greater than 32MB and sluggish performance due to bank- 
ing of Console routines. 

We considered this history and wanted to develop a 
system which included as much machine independence as 
possible. Not only should newer systems with the 64180/ 



Z180 processor be included, but SlOO systems with banked 
memory, addon boards such as Terry Hazen's MDISK for 
the Ampro Little Board, and homebrew systems as well. The 
goal here was as much selfish desire as anything else. By 
developing a single common architecture, only one tool for 
a given purpose would be needed across a variety of ma- 
chines. As an example, Hal has several YASBECs, two SB- 
180s (one modified with static memory), an SB180FX, an 
Ampro Little Board, a couple of mongrel S-100 systems, 
and recently acquired a PI 12. Each system had its own 
Formatter, Configuration utility. Clock type, native disk 
formats, etc. To us, this seems out of place now, particu- 
larly with the scarcity of systems programmers in the Z- 
Community. It made more sense to develop a common soft- 
ware architecture so that more programming resources could 
be devoted to applications type efforts. 

Another goal of the effort was to retain the maximum 
compatibility with existing Z-System software for the same 
reasons cited above. Customizing a huge number of com- 
mon utilities as was done in the XLM-180, seemed to be 
the wrong approach. We therefore decided to retain the 
greatest possible commonality with CP/M 2.2 (actually our 
ZSDOS), and use existing Z-System segments to their great- 
est potential without sacrificing performance. As those of 
you who tracked our efforts as we developed ZSDOS know, 
we do not like slow systems or large code sizes (TCJ issues 
37 and 38). We also decided that our architecture had to be 
capable of outrageous expansion and extension capabilities 
without invalidating previous software efforts. Further, we 
wanted to create a general purpose banked memory inter- 
face that allows applications programs as well as the oper- 
ating system to access alternate banks of memory. The fi- 
nal results are the Banked & Portable (B/P) Bios. 

B/P Bios attacks the memory problem in a manner 
which is easily adaptable to different hardware. All 
HD64180/Z180-based systems bank memory in 4k slices, 
and many SlOO and addon systems bank in 16 or 32k incre- 
ments. We therefore decided on an architecture which re- 
tains common memory in the upper 32k of address space 
(8000-FFFFH), and switches the lower 32k (0-7FFFH) 
among any available banks of RAM. Figure 2 displays this 
architecture pictorially. 



FFFFH 



8000H 



OOOOH 



BANK1 



BANKO 



System 



User 



RAM Disk 



Max Bank 



Figure 2. B/P Bios Memory Scheme 
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BNKl is ALWAYS present in the address space and is 
referred to as the Common Bank. It contains all Z-System 
buffers, Common portions of the Bios, BDOS and the Com- 
mand Processor as well as the upper portion of TPA. Part 
of the Bios which makes B/P unique is the structure which 
allows controlled access to other banks in the lower 32k. 

At least one 32k bank is required in a minimal banked 
B/P system. The system bank, as a minimum, holds por- 
tions Bios and a copy of the Command Processor which 
speeds Warm Boots by simply copying the banked code to 
the Common bank and executing the warm entry. Figure 3 
depicts memory use in a maximally-configured banked sys- 
tem. In such configurations the System bank holds banked 
portions of; the ZSDos2 operating System, banked Command 
Processor, BIOS, and Hard Disk allocation bit maps. 
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Figure 3. Fully-banked Memory Map 

The B/P Bios began with one of Cam's superb archi- 
tectures. He started with the standard CP/M 2.2 Jump Table, 
added in those from CP/M Plus with changes to correct some 
of the inconsistencies, then added in a new series to permit 
logical and easy access to new routines. The code, in as- 
sembly source form, was divided into logically functioning 
elements, with the greatest possible amount placed into 
machine independent modules. As an example, the Disk 
deblocker and lOBYTE decoder functions are machine in- 
dependent and need no change between systems, while the 
actual disk and character device drivers require custom tai- 
loring for each type of computer. Standard interfaces, in 
terms of register usage and value limits, result in common 
software requirements across vastly different hardware sys- 
tems. 

Each software module of the Bios includes relocation 
directives to the assembler telling it whether the code is to 
go into the main memory, or into another bank of memory. 
If a non-banked system is assembled, all code is placed into 
the main 64k area, while banked systems use the main 64k 
area for common code and data as well as banked code and 
data areas. All tools (formatter, configuration utility, etc) 
automatically accommodate both types of Bios without any 
intervention. The choice of whether to bank each section 
of code or not was painstakingly examined for performance 
and size penalties. Many of our design choices may be 
debated, but B/P is here and it works! 



By itself, fixing the Bios is not a complete answer to 
our current Z-System dilemma, but it is a prerequisite. We 
also considered it essential to bank the Disk Operating Sys- 
tem. Starting with ZSDOS, Hal used the new BIOS bank- 
ing functions to bank significant portions of the BDOS. At 
every juncture, size and speed were traded off to keep the 
system small and fast. We corrected the flaw in the CP/M 
Plus Disk Size function cited above by returning four bytes 
containing the number of kilobytes free (a more meaning- 
ful measure). File Time/Date stamping functions for 
DateStamper(tm), P2D0S (CP/M Plus compatible), and Joe 
Wright's NZTIM are all embedded within the Operating 
System and are concurrently active. While ZSDos2 is still 
a work in progress, copies are included in the B/P Bios 
package to allow users to benefit from the newer system. 
Latest versions were posted in the BPBIOS: directory on 
the Ladera Z-Node until its demise, and no replacement is 
yet available. The most recent version of ZSDos2 in 1993 
added directory hashing for true speed demons. 

Also incorporated in ZSDos2 is a ZCPR34-compliant 
Command Line Parser. With the permission of Jay Sage, 
we also modified ZCPR34 to operate in the banked envi- 
ronment, added many common featiu"es of Resident Com- 
mand Processor packages, and simplified it to use the new 
ZSDos2 Command Line Parser. By folding all features into 
the CPR, the need for a Resident Command Processor (RCP) 
extension in high memory all but disappears, typically add- 
ing 2k to the TPA. 

As a closing note to this first installment, systems us- 
ing B/P Bios, ZSDos2 and the expanded CPR are currently 
in operation on the new D-X Designs Pty Ltd P112, 
Micromint's SB180, a modified SB180 with static memory, 
two versions of the SB180FX, three YASBEC configura- 
tions including a laptop with VGA LCD display, Ampro 
Little Board (with Terry Hazen's MDISK expansion), and 
in non-banked mode on a Compu/Time SlOO and Teletek. 
All tools are common across the hardware systems with a 
complete Z3 Environment and additional segments typically 
resulting in the equivalent of a "standard" 60k CP/M sys- 
tem. This size is without the RCP typically used to enhance 
the Command Processor. 

The next part of this article will describe the B/P Bios 
interfaces and standards, while part 3 will cover proposed 
standards for the evolving ZSDos2, its associated Command 
Processor and some of the support utilities. 



Cameron "Cam" Cotrill is a Senior Software Engineer 
with Symantec. 

Harold "Hal" Bower retired from the US Army Signal 
Corps in 1990 and has been active in microcomputing 
since 1976. 
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Special Feature 
All Readers 



Program This! 

The PC Serial Ports 



PC Terminal Programs 



By Dave Baldwin 



The Chips 



PC serial ports are the result of deci- 
sions made in 1980 and never changed 
since then. The 8250 UART from 
National Semiconductor was chosen for 
the original PC's. It is a simple, single- 
buffered design that is only slightly 
more advanced than the old AY-5-1013 
hardware uart. It has a bunch of extra 
bus control signals designed to make it 
'easy' to interface to just about any CPU. 
It also has all of the modem control 
signals available along with two 
undedicated outputs. 

Other designs of the time were double 
buffered (like the 8251) or triple buff- 
ered (like the Z80-SIO) meaning that 
you could wait longer to read the re- 
ceived characters without losing data. 
These other chips had limits of their 
own, however. Neither had all the 
modem control signals, the 825 1 has to 
have CTS true to transmit and the SIO 
is designed to work with the Z80 inter- 
rupt structure. 

Newer versions of the 8250 have been 
introduced including the 8250A, the 
16450, and the 16550. The 8250A fixed 
a couple of errors in the original chip, 
the 16450 provided a faster access time, 
and the 16550 included 16-byte receive 
and transmit fifos. There are also 
CMOS versions, the 82C50A and the 
16C450. All of them power up to act 
like an 8250 (almost). The fifos on the 
original 16550 didn't work, so a 16550A 
version was introduced with working 
fifos. 16650 and 16750 versions with 
larger fifos are also available now from 
other manufacturers. 

The Programs 

Two programs are presented here, one 
in ASM86 and one in 'C A third 
program, SIMPLTRM.ASM will be 
available on the BBS and the TCJ Web 



SCTERM - Simple C Terminal program, June 1997, by Dave Baldwin 
See Issue #80 of The Computer Journal for more info 
about this program. Names of the equivalent labels in 
SIMPLTRM and DOSTERM are in parentheses here. 
TCJ Web page: "http://www.psyber.com/-tcj/" 
Phone: 800-424-8825 



Written for BorlandC 3.1 */ 

^include <stdio.h> 
#include <dos.h> 
^include <conio.h> 

^include "SCTERM. H" 

#define _CPPARGS 

/* prototypes */ 

unsigned int keychk(void) ; 

unsigned int getkey(void) ; 

void interrupt ( *oldvect)( CPPARGS);/' 



void interrupt com_isr( 
void getcmd(void) ; 
void com enb (void) ; 
void com~dsb (void) ; 
char com~in(void) ; 
void com~out(char pch) ; 
/* variaEles */ 
char sch ; 

unsigned int kch,kchx ; 
int xflag « ; 
char int mask ; 
char new~mask ; 
unsigned pic_mask • 0x21 
unsigned pic_eoi = 0x20 ; 
char recerr J 
int i,j,k ; 
char portnum = : 
char com_buf[BUFSIZE] ; 
unsigned buf_hed 
unsigned buf tal 



CPPSRGS 



/ 

/* 

/* 

/* 

/* 



pointer to save old vector */ 
interrupt service routine */ 
get function key cmd*/ 
corn-port set up */ 
com-port disable */ 
get receive char from buffer*/ 
/* send char to serial */ 



/* character from serial port buffer * 

I* characters from keyboard */ 

/* program exit flag */ 

/* old interrupt mask */ 

/* new interrupt mask */ 

/* 8259 mask port address */ 

/* 8259 End-Of-Interrupt port address 

/* miscellaneous ints */ 



/ 



/* 
/• 
/' 



char'signon(T_= "^CTERM using COM" 
-I 



receive buffer */ 
buffer char in index */ 
buffer char out index */ 



char signon2[] 
char tcjmsg[ 
char exitmsg 
char helpmsg 



F10 to exit.\r\n" ; 
From The Computer Journal, (800) 424-8825\r\n" ; 
"SCTERM terminal program in C.\r\n" ; 
"SCTERM/x where x = 1-4 for COMI thru C0M4.\r\n" 



int inain(int argc, char *argv[l) 

/* force value for test */ 
comp.base ° ; 

/* (initOI) command line check here */ 
if (argc==2) 

/* check for port number */ 

i»0; 

k>=0; 

while (argv[1][i]) 

if (argv[1]Ii++] != '/') 

{ 
continue; 

portnum = argv[1] [i] ; 
break ; 
} 
} 



'•I 



10 
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/* (initab) */ 



/* (initab) */ 



/* (initab) */ 



/* (initab) */ 



if (portnuin»»'4' ) { 
comp.base ■ COM4; 
comp.intr » C0M4IRQ; 
conp.imsk - C0M4MSK; 

if (portnuin»-'3') { 
comp.base • COM3: 
comp.intr » C0M3IRQ; 
conp.imsk - C0M3MSK; 

if (portnum"'2') { 
comp.base • COM2; 
comp.intr - C0M2IRQ; 
comp.imsk - C0M2MSK; 

if (portnum-"'! ' ) { 
comp.base •■ C0M1 ; 
comp.intr » C0M1IRQ; 
comp.imsk - C0M1MSK; 

/* default value */ 
if (comp.base "= 0) { 

portnum » '2' ; 

comp.base » COM2: /* (initab) */ 

comp.intr - C0M2IRQ; 

comp.imsk - C0M2MSK; 

/* (comptr) initialize address variables for comm port regist 

comp.ier ■ comp.base+IER ; 

comp.iir •> comp.base-t^IIR 

comp.ier • comp.base-fLCR 

comp.mcr • comp.base+MCR 

comp.lsr ' comp.base+LSR 

comp.mst - comp.base+MST 

comp.scr ■ comp-base-t-SCR 

comp.baudlo > comp.base ; 

comp.baudhi - comp.base+1 ; 

/* initialize memory copies of register values for com port */ 

cr eg. baud > 12 ; 

creg.lcr " 3 : 

creg.mcr » OxOb ; 

/* (initOS) clear screen, setup serial port and interrupt vector */ 

clrscrO; 

com enb() ; 

/* Hisplay signon messages */ 

cputs(signon) ; 

putchjportnumj ; 

cputs(si9non2) ; 

cputs(tc]msg) ; 



:ers */ 



/* (main) »■ 



MAIN PROGRAM LOOP 



while (xflag ■» 0) 

{ /* while the exit flag is zero 

/* check for keyboard input */ 



if (keychkO & Oxff 
kch " getkeyO 
- -<ff 



) { 



/* get char from keyboard */ 
if (kch & Oxff) com out(kch);/* if the key input notzero, ' 
~ /* send it to the serial port 
get function key command */ 



/* 
if 



} 



else getcmdO; 

check for serial input */ 
(buf tal != buf hed) { 

scH = com_in(T ; 

if (sch) putch(sch) ; 



Program EXIT 



I* 



/* 
/* 
/* 



compare head and tail ptrs */ 
get char from serial buffer */ 
display it on the screen */ 



/* (prgxt) -"== 
com_dsb ( ) ; 
clrscrO ; 
cputs|exitmsg) ; 
cputs(tc]msg) ; 
return ; 
} 

unsigned int keychk(void) { 

union REGS regs; 

int c ; 

regs. h. ah « 1; /* check for key ready 

int86(0x16, iregs, iregs); 

c - regs. X. flags & 0x40 ; 

c *" 0x40 ; 

return c ; 

} 



/* turn off serial port */ 



pages. The source code for it is too 
long to fit in the magazine. I may offer 
all the code from this issue on a disk if 
people ask for it. 

These programs will work on any PC 
from an XT to a Pentium and are simple 
enough that you can modify them for 
your own uses. The ASM programs 
(DOSTERM and SIMPLTRM) can be 
assembled with MASM 4.0 or 5.1, 
Borland's TASM 3.0, or the public 
domain Arrowsoft xS6 Assembler along 
with the Val linker. These last two 
were found on the Dunfield Develop- 
ment web site and are now on the TCJ 
Web pages and the TCJ/DIBs BBS so 
you can download them. The 'C ver- 
sion was done in Borland C 3.1. 

Since MS-DOS and the PC BIOS (like 
CP/M) don't do anything useful with 
the serial ports, each of these programs 
does it's own serial port setup. 
DOSTERM sets up the port for polled 
operation and uses MS-DOS for key- 
board and display. If you have 
ANSI. SYS loaded, it gives you a very 
simple ANSI-PC terminal. SIMPLTRM 
and SCTERM set the port up for inter- 
rupt driven operation on receive and 
polled operation on transmit. This is 
the only 'universal' setup for interrupt 
operation. Transmit and status inter- 
rupts and bugs vary enough between 
the chips to require some testing and 
special handling in the interrupt ser- 
vice routines. 

If you decide you want to use transmit 
and status interrupts, you need to get a 
copy of 'The Serial Port FAQ' by Chris- 
tian Blum which is now available on 
the TCJ web site and BBS. There are 
problems with transmit interrupts dis- 
appearing on some chips and the inter- 
rupt response for multiple interrupts is 
different. An interrupt service routine 
that takes all of these into account is 
shown in The Serial Port FAQ and is 
many times longer than the one I'm 
using here. 

I've put a couple of special 'features' in 
these programs. The ASM programs 
are set up so that they will run as EXE 
or COM programs. I did this when I 
got tired of having to run EXE2BIN 
before I could check the results of the 
next 'newer, better' version. This also 
helped when I started making larger 
versions that needed to be EXE only 
programs. Also, having the three dif- 
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ferent versions lets you compare what's 
been done and see the different ways of 
doing essentially the same thing. I've 
also tried to kept the names of the rou- 
tines the same in all three versions so 
you could compare them. Another thing 
is that these are all small programs. 
Even the 'C version is less than 
lOkbytes after it's compiled. 

All the programs are organized the same 
way. After defining some values, they 
check the command line to see if you 
want COMl instead of COM2 which is 
the default port. Then they set up an 
address table based on the address of 
the comm port you're going to use, 
enable the comm port, clear the screen, 
and put up the signon messages. The 
'com_enb' routine is called to initialize 
the serial port. Since DOSTERM uses 
the MS-DOS console routines, the 'clear 
screen' is done as an ANSI escape se- 
quence in the signon message. 

Enabling the Serial port 

Before you can use the serial port, you 
have to program the chip and set up the 
interrupt vector if interrupts are going 
to be used. SIMPLTRM and SCTERM 
use the MS-DOS functions to get the 
old interrupt vector and save it so it can 
be restored when the program exits and 
then set the vector to point to their own 
interrupt service routine, 'com_isr'. 
Next, all three programs program the 
serial chip registers to the values needed 
for operation. 

The 8250 family has 9 or 10 address- 
able registers. The 'Scratch' register 
doesn't exist on the earliest versions. 
In ASM86, only the 8-bit I/O addresses 
from to 255 are directly addressable. 
For 16-bit I/O addresses, you have to 
load the DX register with the address 
and input or output to/from the AL or 
AX register. Since the 8250 registers 
are all byte registers, we'll be using 
oidy AL. 

The first thing we do is to disable all 
interrupts from the chip while we're 
programming the rest of the registers 
by setting lER (Interrupt Enable Regis- 
ter) to 0. Then we send an 83h to the 
LCR (Line Control Register) to select 
the baud rate registers. The 8250 has 
an internal baud rate generator with a 
16-bit divider that can divide the baud 
rate clock with values from 1 to 65535. 
Divide by is undefined as usual. 



unsigned int getkey{void) { 

union REGS regs; 

regs.h.ah = ; /* get key */ 

return int86{0x16, &regs, &regs); 

} 



void getcmdO { 
kchx » kch/256 ; 
if (kchx "= 68) 

xflag = -1 ; 

if (kchx "» 59) 

clrscr() ; 
cputs(signon) ; 
putch(portnuin) 
cputs|signon2) 
cputsftcimsg) 
■ sip 



/* if it's zero, then get extended char */ 



is it FIG? */ 

then set exit flag */ 



is it F1? */ 

then clear the screen 



} 



cputs(helpnsg) 
} 



/* COM_IN */ 

char coin_in(void) { 

char tch ; 

tch " con buf[buf_tal] ; 

position '*'/ 

buf tal++ ; 

bufltal - buf_tal & BUFMSK 

return tch ; 
} 



/* get byte from current buffer 

/* adjust buf pointer */ 
and mask and resave it for next 
time */ 
/* return the char from the buffer */ 



/* COlyi_OUT */ 

void com_out(char pch) { 

int cntr « 1000 ; /* time-out counter to prevent lockup 

char tst ; 

while (cntr-) 

{ /* check time-out counter */ 

tst = inp(comp.lsr) & 0x20 

if (tst) 



outp ( comp . base , pch ) 
cntr = ; 
break ; 
} 



/* 
/* 
/* 



test THRE */ 

if true, send char 



/ 



set loop counter to zero 
/* and exit */ 



} 



/* clear fifo pointers */ 



I* COM_ENB */ 

void com_enb (void) { 

buf_hed - ; 

buf tal - ; 

/* save the old interrupt vector */ 

oldvect » getvect(comp.intr) ; 

/* install the new interrupt handler */ 

setvect(comp.intr, com_isr); 

/* disable interrupts while we set up port */ 

disable () ; 

/* set up serial port registers */ 

outp(comp.ier,0) ; /* serial chip interrupts off */ 

outp(comp.lcr,0x83) ; /* access baud rate registers */ 

outp(comp.baudlo,creg.baud) ; /* divide by 12 for 9600 baud, low 

byte */ 
outp ( comp. baudhi.creg. baud » 8); /* high byte of baud rate divider */ 
outp(comp.lcr,creg.lcr) ; /* set 8N1 */ 

outp{comp.mcr,creg.mcr) ; /* turn on DTR, RTS, and 0UT2 */ 
/* do dummy reads to clear flags */ 
inp(comp.base) ; 

inp(comp.lsr) ; , .. , 

outp(comp.ier,1) ; /* serial receive interrupts only */ 

/* re-enable interrupts now */ 
enable ; 

/* set up interrupt mask in PIC */ 
int_mask » inp(pic mask); 
new_mask = int_masl< & (Icomp.imsk) ; 
outp(pic_mask,new_mask) ; 
} 

/* COM_DSB */ 

void com_dsb (void) { 

outp(comp.ier,0) ; /* serial chip interrupts off */ 

outp(comp.mcr,0) ; /* modem control lines off */ 

/* restore the old interrupt mask */ 

int_mask = inp(pic mask); 

new mask = int_masl< | comp.imsk ; 
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outp(pic_nask,new mask) ; 

/* restore the ol3 interrupt handler */ 

setvect(co«ip.intr, oldvect); 

} 

/***NOTE: 

This is an interrupt service routine. You can NOT compile this 
program with Test Stack Overflow turned on and get an executable 
file which will operate correctly. */ 

#pragma -N- /* stack checking off */ 

/* COM_ISR */ 

void interrupt com isr( CPPARGS) { 

recerr » inp(comp.Tsr) ; 

com_buf [buf_hed] » inp(comp.base) ; 

buf hed++; 

buf'hed - buf hed & BUFMSK ; 

outp(pic eoi,Cx20) ; 

} 



/* read/clear error byte */ 
/* read data byte */ 
/* adjust and mask pointer */ 

/* send EOI to 8259 */ 



/* SCTERM.H - header file for SCTERM.C 
/* COM port and buffer equates */ 



'I 



#define C0M1 0x03f8 
#define C0M1IRQ OxOc 
#define C0M1MSK 0x10 
#define COM2 0x02f8 
#define C0M2IRQ OxOb 
#define C0M2MSK 0x08 
#define COM3 0x03e8 
#define C0M3IRQ OxOc 
#define C0M3MSK 0x10 
#define COM4 0x02e8 
#define C0M4IRQ OxOb 
«define C0M4MSK 0x08 



/* for C0M1 */ 



/* for COM2 */ 



/* for COM3 */ 



/* for COM4 */ 



#define BUFSIZE 0x2000 /*receive buffer size, must be power of 2 
#define BUFMSK BUFSIZE-1 /* 1 Less for mask */ 



#define BASE 
#define lER 1 
#define IIR 
#define LCR 3 
#define MCR 4 
#define LSR 5 
#define MST 6 
#define SCR 
#define RTS 2 

struct comdef { 
int base ; 
int ier 
int iir 
int Icr 
int mcr 
int Isr 
int mst 
int scr , 
int baudio ; 
int baudhi ; 
char intr ; 
char imsk ; 
} comp; 

struct COMREG { 
unsigned int baud 
unsigned char Icr 
unsigned char mcr 
} creg ; 



/* Base (No real reason to have this) 
/* Interrupt Enable Register */ 
/* Interrupt ID Register */ 
Line Control Register */ 
Modem Control Register */ 
Line Status Register'*/ 
Modem Status Register */ 
/* Scratch Register */ 



/* 
/* 
/* 
/* 



/* rts bit in MCR */ 

/* addresses of port registers plus IRQ and mask */ 



The baud rate registers actually use the 
same addresses as the data and IER 
registers, but they're in a different 
'bank'. You select the baud rate regis- 
ters by setting bit 7 or the LCR to a one. 
The standard PC baud rate clock oscil- 
lator is 1.8432 MHz. To get 9600 times 
16 (153.6 KHz) you divide by 12. You 
put 12 in the lower baud rate register 
and zero in the high register. 

Next we load the LCR with 03h which 
unselects the baud rate registers and 
sets the chip to 8 data bits, no parity, 
and 1 stop bit. The MCR (modem con- 
trol register gets loaded with Obh for 
the interrupt version and 03h for polled. 
The 0UT2 bit has to be turned ON in 
PC serial ports to enable the interrupt 
gate. This is usually a 74LS 125 which 
is in series with the INTR line from the 
chip and the selected IRQ line on the 
bus. 

After that, we do some dummy reads of 
a couple of registers to clear any flags 
that might have been accidently set. 
For the polled version in DOSTERM, 
this is all that's needed. For the inter- 
rupt versions, we still have to set the 
IER to allow receive interrupts and set 
the appropriate mask bit in the 8259 
PIC (Programmable Interrupt Control- 
ler). 

The disable routine, 'comdsb', does 
the opposite of the enable routine. It 
restores the old interrupt vector and 
turns off the serial chip interrupts in 
SIMPLTRM and SCTERM and it turns 
off the modem control lines in all of 
them. SIMPLTRM and SCTERM also 
restore the previous interrupt mask to 
the 8259. 

The Main Loop 



The main program loop checks for a 
keyboard input to see if you want to 
send anything and then it checks to see 
if you have received anything. 
DOSTERM actually polls the serial chip 
each time. SIMPLTRM and SCTERM 
check the receive buffer to see if the 
receive interrupt service routine has put 
any characters in the buffer. 

If there is a keyboard input, it is checked 
to see if it's an 'extended' char code or 
a normal character. Normal characters 
from 1 to 255 are written to the serial 
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port. Extended codes are checked for 
the two commands, Fl and FIO, that 
are used by these programs. Fl is the 
'help' command which redisplays the 
signon info and FIO is the exit com- 
mand. 

If there is an input from the serial port, 
it is sent to the screen. DOSTERM lets 
MS-DOS handle the control characters 
and escape sequences while SCTERM 
let's the video routines built in to the 
Borland 'C compiler do it. 
SIMPLTRM has routines to do the con- 
trol code and escape sequence process- 
ing to emulate the basic functions of an 
ADM3 terminal and uses the PC BIOS 
routines for video output. 

That's really all there is. Each of these 
programs can be used as is or easily 
modified to your own needs. They were 
left as simple as they are so they would 
be reasonably easy to understand. 

One of the limits on these programs is 
speed. Don't expect to go above 19.2 
KBaud (9600 for DOSTERM) without 
errors, bi 'standard' configurations for 
PCs, it turned out that everything from 
a 4.77MHz XT to a 486DX2/66 started 
getting errors above 19.2Kb. The XT 
just plain ran out of steam while the 
background processing caused problems 
on the 386 and 4S6. It turns out that 
background programs like SMARTDRV 
link into to many of the standard DOS 
and BIOS routines and use up enough 
CPU time to limit the interrupt servic- 
ing. When I booted a 386 in a mini- 
mum software configuration, it would 
run without error at 57.6Kb with these 
simple interrupt routines. 

An improved version of SIMPLTRM is 
available for download on the TCJ FTP 
site and the TCJ/DIBs BBS. Called 
DIBSTERM.COM, it let's you select 
which serial port you want to use, tell's 
you what kind of serial chip the port 
has, and allows you to change the port 
while the program is running. It also 
puts the modem line status at the top of 
the screen so you can monitor their 
status and lets you control the outputs 
with function keys. You can also select 
the baud rate (from 50 to 115200) and 
other parameters along with the hand- 
shaking mode. It's a good testing pro- 
gram as well as a simple terminal pro- 
gram. 

Dave Baldwin 



DOSTERM. ASM - a simple terminal emulator for PC's 
TCJ Web page: ''http://vww.psyber.com/-tcj/" 
Phone: 800-424-8825 

Uses MS-DOS console functions 

Uses the PC serial port in polled mode. 

Can be assembled by MASM 4.0 or 5.1, Borland's TASM, 

or the Arrowsoft public domain assembler and Val linker. 
This is a 'COM' program that can also run as an 'EXE'. 
Look for '***' to see what's required to do this. 
There can only one segment, the code (CS) segment. 

EQUATES 
false equ ; 
true equ not false 
cr equ Odh ; 
If equ Oah ; 
; duplex mode 

echo equ false ;false = full duplex, true 
; standard hardware handshake 



half -duplex 



rts equ 2 
handshake equ 
;COM port equates 



;rts bit in com_mcr 

true {include handshake code if true 



com1 


equ 


03f8h 


;for C0M1 


com2 


equ 


02f8h 


;for COM2 


com3 


equ 


03e8h 


;for COM3 


com4 


equ 


02e8h 


;for COM4 



Macros for handshaking routines 

These are used anywhere that video scroll can occur because 
the video BIOS routines turn off interrupts when they scroll. 
RTSOFF MACRO 
: rts OFF 
IF handshake 
push dx 
push ax 
pushf 
mov dx,com_mcr 

'rts OFF 



in 
and 


It 


dx ; 
not rts ; 


out 


dx, 


al ; 


popf 






pop 


ax 




pop 


dx 




END IF 






ENDM 






Stson 


MACRO 


; rts ON 






IF handshake 


push 


dx 




push 


ax 




pushf 




mov 


dx, 


com mcr 


in 


al. 


dx " ; 


or 


al, 


rts ; 


out 


dx, 


al ; 


popf 






pop 


ax 




pop 


dx 




ENDIF 






ENDM 







rts ON 



cseg segment para public 'CODE' 

org 100h ;COM program 

assume cs:cseg,ds:cseg,es:cseg,ss:cseg ;COM program 

dosterm proc far ; entry point from DOS 
; *** set segment reg's for EXE/COM version, all same segment 
mov ax,cs ; 

mov es,ax ;make SS and ES = CS, leave DS = PSP 
mov ss,ax ; 
mov sp,-2 ; set stack pointer 
. *** save psp pointer in real stack along with a '0' 
push ds ; 
xor ax, ax ; 
push ax ; 
;get command tail 

mov bx,80h ; point to command line 
(uses DS as PSP pointer) 
get first byte which is char count 
if (no chars) , 

; use default port (com2) 



mov al,[bx] 
cmp al,0 
je initOb 
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; check the rest of the command line 



initOI : inc bx 

nov al,[bx] 

cmp al," " 

je initOI 



;next char 



;skip spaces 



cmp al,"/" 

jne initOb 

inc bx 

mov alJbx] ; 

cmp al,'?.' 

jne init02 ; 

mov dx, offset errmsg 

jmp prgext ; 



;first non-space char must be slash 
; or else use default port (com2) 
;next char 



jmp if not '?', 
; else show 'errmsg' 
and exit 



init02: cmp al,"r ;is it C0M17 

jb initOb ;if not then use COM2 

cmp al,"4" ; 

jbe initOc 
initOb: mov al,''2' ;set default comm number 

initOc: mov byte ptr com num,al ;save ASCII comm number 
; *** Now set DS - CS because we're done with PSP 

mov dx,cs 

mov ds,dx 
; set con port address table according to 'com_num' in AL 

call comptr 

:put up signon message 

initOS: mov dx, offset signon ;get signon message 

mov ah,09h ; display string function 

int 21 h ;let dos do it 

mov dl.byte ptr com num ;get comm number 

mov ah,06h ~ ; display char function 

int 21 h ;let dos do it 

mov dx, offset signon2 ;get signon message 

mov ah,09h ; display string function 

int 21 h ;let dos do it 



call com enb 



Main program loop 



; start up communications port 



mmmmmmx 



main: 



mov 
int 

jz 
cmp 



mov dl.Offh ; 

ah, 6 ; direct input 

21 h ;ask DOS for keyboard input 

main4 ;no char, skip 

al,0 ;is it extended key code? 

mains ; Yes, go process 



main2: 
if 



;if running half-duplex, echo char 
J to PC display 



echo 
push ax 
call vidout 
pop ax 
endif 

call com out 



;{coM_inp) check if char waiting at comm port 
main4T 

mov dx,com_lsr ;get receive status 

in al,dx ; 

and al,1 ; check receive data ready flag 

jz main ;no, loop 



mov dx,com_base 
in al,dx 
call vidout 
jmp main4 

; check function keys 

mains : 

;get second byte 

mov dl,0ffh 

mov ah, 6 

int 21 h 



data port 

write it to PC display 
see if any more waiting 



direct input 

ask DOS for keyboard input 



;F1? 



cmp al,59 

jne mains ; 

F1 (Help) message 
RTSOFF 

mov dx, off set signon ;get signon message 
mov ah,09h ; display string function 

int 21 h ;let dos do it 



References: 

Advanced MS-DOS 
Ray Duncan 
Microsoft Press 

ASM and C programs for MS-DOS. 
I started out by copying the 
TALK.ASM program from this 
book. 

The Peter Norton PC Programmer's 

Bible 

Norton, Aitken, Wilton 

Microsoft Press 

The 'standard' refence for beginning 
and intermediate PC programmers. 

MS-DOS Programmer's Reference, 
Version 5 
Microsoft Press 

Extensive listing of all the MS-DOS 
functions with short sample 
routines and all of the structures 
used by MS-DOS up to version 
5.0. 

The_Serial_Port_FAQ 
Christian Blum 

Look here for routines for detecting 
and using the 16550 uart with 
fifos for high-speed communica- 
tion. Available on the TCJ FTP 
site. 

National Semiconductor Data 
Communications Handbook 

8250 thru 16550 data sheets. Also 
available from their web site as 
Adobe Acrobat PDF files, "http:// 
www. natsemi . com" 



DIOs 

Electronic Design 

Dave Baldwin 



Microprocessor and Digital 
design and programming. 

Analog circuit design. 

PCB layout and more. 

Voice(916) 722-3877 
Fax (916) 722-7480 
BBS (916) 722-5799 
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INS8250 

■T37- 




nov dl,byte ptr coin_nuin ;get comm number 

nov ah,06h ; display char function 

int 21 h ;let dos do it 

mov dx, offset signon2 ;get signon message 

mov ah,09h ;display string function 

int 21 h ;let dos do it 

nov dx, off set tcjmsg ; restore message pointer 

mov ah,09h ;display string function 

int 21 h ;let dos do it 

RTSON 

mainSm: 
RTSOFF 

mov dx, offset errmsg ;get message offset 
mov ah,09h ; display string function 
int 21 h ;let dos do it 

RTSON 

jmp main ; 



main6: 

jmp 

I 
mainx: 



;F10? 
yes, exit 



cmp al , 68 

mainx 

main ;if not, ignore and loop back to 'main' 

mov dx, offset exitmsg ;print farewell message 



;exit procedure 



Pins: 

1-8 DO thru D7, data lines 

9 RCLK - Receiver clock 

10 SIN - serial input 

11 SOUT - serial out 
12-14 CS1-3 - chip selects 

15 /BAUDOUT- Oscillator 
output 

16 XIN - crystal Input 

17 XOUT - crystal output 
18-19 WR - write control 

20 VSS (gnd) 
21-22 RD - read control 

23 DDIS - driver disable 

24 CSOUT - chip select out 

25 /ADS - address strobe 
26-28 A0-A2 - address lines 

29 NO 

30 INTR - interrupt output 

31 0UT2 - used to enable PC 
Interrupts 

32-34 Modem/control outputs 
35 MR - Master reset 
36-39 Modem/control inputs 
40 VCC - +5V 



prgext: 



* set DS in case of error exit 
mov ax,cs 
mov ds,ax 
mov es.ax 



push dx 
call com_dsb 
pop dx ~ 

mov ah , 9 
int 21 h 



;save message address 

; disable controller and release int vec 



;let DOS print message 



mov ax,4c00h ;exit with ret code 
int 21 h 



ret 

int 20h 

dosterm endp 

vidout proc near 

RTSOFF 

mov dl,al 

mov ah, 6 

push bx 

int 21 h 

RTSON 

pop bx 

ret 
vidout endp 



;far return just in case 
;just in case 



;write char in AL to display 



;use DOS DIRECT console 
;save bx 
;call DOS 



; send char in AL to serial port 
com_out proc near 

push ax ;save char 

mov dx.com Isr ; check tbe stat 

mov ex, 2005 ;anti-lockup 
com_out1 : 

in al,dx 

and al,20h 

inz com_out2 

loop com_out1 

pop ax ~ 

ret 
com_out2: 
"pop ax 

mov dx,com_base 

out dx,al 
com_oxt : 

ret 
com_out endp 



;THRE 
send if ready 
loop until ready 
restore char 



jwrite char to port 



; set up comm port 
com_enb proc near 

mov dx,com_ier ^interrupt enable register 
mov al,0 ; no interrupts 
out dx,al ; 



mov dx,com_lcr 
mov al,83h 



;set line control 

; select baud reg, set parms below 
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out dx.al ; 

mov dx,coin_base ;set 9600 baud 

piov al.Och ;lo byte 

out dx,al ; 

inc dx ; point to high byte 



xor al,al 

out dx,al 
set r/t parns 

mov dx,coin_lcr 

nov al,03h 

out dx,al 

nov dx,co«i_iicr 

mov al,03h 

out dx,al 

mov dx,com_base 

in al,dx ~ 



mov 
in 



dx.com Isr 
al.dx ~ 



;high byte is 

;unsel baud reg, no parity, 1 stop, 8 bits 
f 

; modem controller DTR, RTS, 



; dummy read of serial port 
; to clear flag 



; dummy read to clear stat flags 



ret 
com_enb endp 



; turn modem control outputs off 

com_dsb proc near 

mov dx.com mcr ; 

mov al,0 ~ ;turn off all mcr outputs 

out dx,al ; 

ret 

com_dsb endp 

; gets base pointers and updates I/O address table 

comptr proc near 

mov bx, off set porti ; offset to port1 

cmp al,'1' ; 

jz comset ; 

mov bx, offset port2 ; offset to port2 

cmp al,'2' ; 

jz comset ; 

mov bx, off set port3 ; offset to porta 

cmp al,'3' ; 

jz comset ; 

mov bx, off set port4 ; offset to port4 

cmp al,'4' ; 

jz comset ; 

mov dx, offset errmsg ;EXIT because no COM specified. 

xor ax, ax ; 

ret 
;load I/O address table for selected com port 
comset: 

mov ax,[bx] ;get base 

or ax, ax ; check for zero 

jz comptx ;zero error exit 

mov word ptr com_base,ax ; 

mov word ptr baudlo.ax ; 

inc ax ;+1 for ier/baudhi 

mov word ptr com_ier,ax ; 

mov word ptr baudhi,ax ; 

inc ax ; 

inc ax ;+2 for lin 

mov word ptr com_lcr,ax ; 

inc ax ;+1 for mcr 

mov word ptr com mcr, ax ; 

inc ax ~ ;+1 for stat 

mov word ptr com_lsr,ax ; 

inc ax ;+1 for mst 

mov word ptr com_mst,ax ; 

comptx: ret 

comptr endp 

com port address assignments 

porti dw com1 ;port address 



port2 dw 
ports dw 
port4 dw 



com2 
com3 
com4 



;port address 
;port address 
;port address 



More advanced programs 

In more complete terminal emulations 
and file transfer programs, the serial 
code is a small part of the program. 
Terminal emulations require direct 
video routines because the PC BIOS 
routines are inadequate and too slow, 
file transfers require a lot of code for 
the different protocols, and both require 
code to control the modem. 

There are several other problems that 
need to be dealt with on PC's. You may 
need a 'CPU ID' routine to tell you what 
kind of machine your program is run- 
ning on. Plain PCs and XTs only have 
the low order interrupts available 
(IRQO-7) while the AT/386/486/ 
Pentiums have IRQ's thru 15 avail- 
able. If your program needs to be able 
to use high order IRQs (9-15), you will 
need a slightly different interrupt ser- 
vice routine for your receive interrupt. 

On a PC, you also need to provide a 
'Critical Error Handler' routine so that 
disk file problems don't crash your pro- 
gram. The 'default' action of the Critcial 
Error Routine (Abort, Fail, Retry?) will 
abort your program and return to DOS 
if you don't provide a routine that gives 
your program control. 

You also need to 'intercept' the timer 
interrupt to eliminate software timing 
loops. Since fixed software timing loops 
will run at drastically different rates on 
different PC's, using the timer inter- 
rupt will allow you to have consistent 
timing on different machines. 

Another problem is 'handshaking' on 
the serial ports. Handshaking is used 
to start and stop the flow of data to 
allow the programs to do something 
else for a moment like reading or writ- 
ing files or scrolling the screen. 
DOSTERM shows very simple hard- 
ware handshaking (RTSOFF/RTSON). 
Some situations require other modem 
control lines for handshaking and there 
are several different kinds of software 
handshaking. 

And then there's modems. They have 
to be sent 'AT' command strings in the 
proper order and you have code to rec- 
ognize the responses to know what to 
do next. TCJ #79 has David 
Goodenough's article on the AT mo- 
dem commands. 
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;progran uses this table after setup 

con base dw ; 

coii~ier dw ; interrupt enable reg 

coii~lcr dw ;line control 

con~ncr dw ; modem control 

com Isr dw ;line status reg 

com~mst dw ; modem status reg 

bau3lo dw ;baud divisor lo 

baudhi dw ;baud divisor hi 

tblsiz equ $-com_base 

com num db ; ASCI I conm number 

signon db 27, "[2J" [ANSI 'clear screen' 

db "DOSTERM using COM$",0 

signon2 db ", F10 to exit >",cr,lf ."S" 

: Note '0' at end of first line for use by 'F1' / help function. 
errmsg db 'Type DOSTERM /x where 'x' is 1-4 for C0M1 thru C0M4.",cr,lf ,0 
db -Display must be text mode.'.cr.lf ,0,"$" 

•xitmsg db cr, If, 'Exit from DOSTERM terminal emulator. ' ,cr, If 
tcimsg db 'From The Computer Journal, (800) 424-8825', cr, If 
db 'Web page: http://www.psyber.com/-tcj/' ,cr, If , '$' 

cseg ends 

end dosterm 



8250 Register Addresses 






DLAB=0 



DLAB=0 


1 
DLAB=0 


2 


3 


4 


5 


6 



DLAB=1 


1 
DLAB=1 


register 
bit 


RECV 

buffer 

register 


TRANS 
holding 
register 


Interrupt 
Enable 
register 


Interrupt 

ID 
register 


Line 
Control 
register 


Modem 
Control 
register 


Line 
Status 
register 


Modem 
Status 
register 


Divisor 

Latch 

low 


Divisor 

Latch 

hi 





DBO 


DBO 


Recv 

data 

available 


•O'if 
Interrupt 
pending 


Word 

Length 

bitO 


DTR 


Recv 

Data 

Ready 


Delta 
CTS 


BitO 


Bits 


1 


DB1 


DB1 


Transmit 
holding 

reg 
empty 


ID bit 


Word 

Length 

bit1 


RTS 


Overrun 
error 


Delta 
DSR 


Bit1 


Bit 9 


2 


DB2 


DB2 


Recv 

Line 

Status 


ID bit 1 


Number 

of Stop 

bits 


Out1 


Parity 
error 


Trailing 
edge 
Ring 

Indicator 


Bit 2 


Bit 10 


3 


DB3 


DBS 


Modem 
Status 





Parity 
Enable 


Out2 
(PC INT 
enable) 


Framing 
error 


Delta 
DCD 


Bit 3 


Bit 11 


4 


DB4 


DB4 








Even 
Parity 
Select 


Loopback 


Break 
Interrupt 


CTS 


Bit 4 


Bit 12 


5 


DBS 


DBS 








Stick 
Parity 





Transmit 

Holding 

register 

empty 


DSR 


Bits 


Bit 13 


6 


DB6 


DB6 








Set 
Break 





Transmit 

Shift 

register 

empty 


Ring 
Indicator 


Bite 


Bit 14 


7 


DB7 


DB7 








Divisor 

Latch 

Access 

Bit 
(DLAB) 








DCD 


Bit 7 


Bit IS 
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Real Computing 



By Rick Rodman 



32-Bit Systems 

All Readers 
Real-time Control 



August in the Nation's Capital: ragweed pollen floats in the 
hot, sticky air. Gnats and mosquitos greet them that dare 
venture out from air conditioning and HEPA filter. It is a 
time for reflection, for contemplation of possibilities, for 
antihistamines, most of all for staying inside. 

The Timer 

As an old saying goes, when life hands you a lemon, make 
applesauce. Many times we look in the wrong place for a 
solution to what is really a simple problem. Part of my plans 
and thoughts regarding my Real-Time Control System cen- 
ter around avoiding utility waste, and one of my pet peeves 
is lights being left on - particularly in the basement, but also 
in bathrooms. This has led me to try various timer devices, 
X-10 modules, timer controllers, and RTCS. But now I've 
found a much simpler solution. 

This is a device available from Marlin P. Jones Associates, 
called a "SSAC TS120A-966 Solid State Timer", which the 
catalog says "supplies 115VAC@1A max to the load for 30 
min. then power is removed from the load". What it really 
does is, it turns off lights after 30 minutes. (Sony, no shorter 
durations are available.) It does the job perfectly, it's simple 
to connect and it costs only $3.75. 

The MPJA catalog is a candy store for experimenters, full of 
neat optoelectronics, power supplies, unusual switches, con- 
nectors and other exciting stuff. Maybe I'll finally get around 
to building the Chaos-Pandemonium Box. 

Newton 

As the Chinese say, a journey of a thousand miles begins 
with a single stumble. Some readers will remember Apple's 
other personal computer, the Newton, with its crummy hand- 
writing-recognition technology. The Newton not only cost 
$800, but it required a souped-up Macintosh and an expen- 
sive development kit even to do the simplest programming - 
and, on top of all that, used its own proprietary language, a 
very weird object-oriented dialect called NewtonScript. In 
management, and in baseball, they say a project can survive 
one big mistake, might survive two, but three strikes and 
you're definitely out. 

Well, now that monied interests have moved to greener pas- 
tures, there remains fertile ground for enjoyable experimen- 



tation. Used Newtons are available cheaply - sure, they're 
not the latest models, but there haven't been that many 
changes in the line. Better yet, an inexpensive development 
tool is available, Steve Weyer's Newt. Newt, and its com- 
panion Slurpee, let you do typing on a PC - or a Sun or 
Kaypro or anything at all, really - and compile on a Newton. 

Once you realize that a Newton is not suitable for any sig- 
nificant data entry, you start thinking that there's a lot of 
stuff that'd be really neat to do. One thing I want to do on it 
is for my car, to keep records, perform milage calculations 
and remind me about oil changes. 

A CD of Newton programs is available from AMUG. While 
there appears to be no source code on this CD whatsoever, 
there are plenty of programs, mostly shareware, which may 
do what you want to do. In fact, one program, called MPG2, 
does exactly what I described in the previous paragraph. 

Apple Computer recently released a beta of the long-antici- 
pated Newton Toolkit for Windows, which actually requires 
Windows 95 or NT, and you can download it from their Web 
site. 

Probably I won't write much more about Newton topics un- 
less our esteemed editor prompts me, but for the TCJ reader 
the relevant facts are: ARM RISC processor, 128K to 512K 
of internal RAM, 1, 2 or 4MB flash card, graphic display 
with stylus input, no disk or keyboard, one RS-232 serial 
port. 

Java 

They say you can lead a gift horse to water, but don't look 
him in the mouth. From an informal survey of books in lo- 
cal bookstores, it looks like Java is far and away the most 
popular programming language today, outpolling Visual 
Basic and C++ combined. So what is it? It's a compiler/ 
interpreter, like BASIC-E, CBASIC, and UCSD Pascal. A 
web page containing an "applet" causes a browser to request 
that "Java Byte Code" (p-code) be sent, where a "Java Vir- 
tual Machine" (interpreter) runs it. Nothing particularly 
innovative about that, is there? Of course it has the usual 
object-oriented stuff like classes and methods that are de 
rigeur these days. 

While people always rush to say "it's a lot like C++", this is 
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not true. It has none of C-h-'s hard-to-read double colons or 
overloaded operators or templates or virtual functions, fea- 
tures which nobody in their right mind would use anyway. 
Some of its declarations look more like Pascal. 

The most important difference between Java and C or Pas- 
cal is that Java doesn't have any pointers. Although point- 
ers use a quirky syntax in C and are a minefield for the un- 
waiy, they are actually the language's most powerful fea- 
ture. Wifliout pointers, we're reduced to pass-by-reference/ 
pass-by-value, like we had to do way back in the Fortran days. 
In fact, because of Java's syntax, I think the best alternative 
name for it is... Object Ratfor. 

Microsoft's motto is "Good things come to those who waste", 
and they hope to crush Java in their deadly embrace. They 
have announced a package called "Visual J++", which is a 
version of Java modified to support what are now called 
"Active X Objects" (formerly called "OCXs" and "OLE Cus- 
tom Controls"). The name "J++" is supposed to look like 
"C++" (repeating the mistake that name makes), but 
Microsoft, in their usual narrow vision, didn't notice that 
there is a very popular language called J, a derivative of APL. 
Anyway, Visual J++ looks like a package that can be safely 
avoided. 

In Windows 95 and in NT version 4, the once small, quick 
Write word processor, which has been getting bigger over 
time, is replaced by a new program called WordPad. From 
what I can see, it has nothing that Write didn't have. But 
now, thanks to Microsoft's "dogfooding", it uses MFC and 
takes ten times as long to load. Efficiency is evidently a 
dirty word at Microsoft. I wonder if Bill Gates, the hotshot 
programmer who cajoled a full BASIC interpreter into the 
Altair's limited RAM, knows or cares what schlock his min- 
ions are producing. 

More on Small-C for embedded systems 

Frank Wilson writes to say that he has used CUG 6809 Small 
C to do work on a Color Computer and on a small 6809 SBC, 
and fixed a lot of bugs in it. "The 'logical not' code genera- 
tion portion screws up the stack. Also, I think the integer 
divide had a sign problem. Eventually the darn thing would 
self compile on the CoCo, and I also got it to compile on a 
68HC1 1." He also says: "Maybe using a PC for cross devel- 
opment is cheating, but it simplifies things and makes fool- 
ing with obsolete processors a low cost option." I don't think 
it's cheating, Frank. After all, a PC has to be good for some- 
thing, doesn't it? 

He also mentions some cross assemblers which are on CUG's 
CD. Most ofthese are fairly crude. The ones I like best are 
the Frankenstein cross assemblers. When working with as- 
sembly code, what can seem very minor syntax variations 
can just drive you crazy, especially when it comes to mac- 
ros. In the Unix world these things are often standardized, 
but in the wild-and-woolly PC world, you never know what 
to expect. 



You've seen the movie, now get the OS 

The Plan 9 distributed operating system, named for the movie 
"Plan 9 from Outer Space", is available from AT&T in source 
code form for $350. 

Next time 

The RTCS becomes more truly real-time as it meets the TW- 
523 X-10 interface and the Watson voice card. Plus, time 
and space permitting, the difference between 'sound' and 
'voice' and how to overcome it. Remember, it's not what 
your computer has, but what you can do with it! 

For more information 

Kettle Pond Computing Facility 

BBS or Fax: +1 703 759 1169 

E-mail: ricker@erols.com 

Mail: 1150 Kettle Pond Lane, Great Falls VA 22066-1614 

Marlin P. Jones Associates: 
1 800 652 6733 or +1 561 848 8236 
Timer, item # 4381-RL, $3.75 
P.O. Box 12685, Lake Park FL 33403-0685 

Steve Weyer (Newt Development Environment, etc.) 
weyer@netaxs.com 
17 Timber Knoll Drive 
Washington Crossing PA 18977 

AMUG CD Inc. (Totally for Newton CD #6, $24.95) 

+1 602 553 0066 or -0144 fax 

745 N. Gilbert Road #124-275, Gilbert AZ 85234 

AT&T (Plan 9 operating system, $350): +1 908 577 2700 
2 Paragon Way, Suite 400 
Freehold NJ 07728 



LINUX 

InfoMagic 5 CD Set $21.95 

Yggdrasil $29.95 

Linux man Pages $29.95 

The New Book of Linux $29.95 

Call for other titles 



www.Justcomp.coni 

on the World Wide Weh 



JUST COMPUTERS! 
(800) 800-1648 

Fax (707) 586-5606 Infl (707) 586-5600 
P.O. Box 751414, Petaluma, CA 94975-1414 

E-mail: sales@justcomp.com 
Visa/MC/Int'l Orders Gladly Accepted 
For catalog, send e-mail : info@justconip.com 
Include "help" on a single line in the message. 
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Cheap Hard 
Controllers 

by Allison Parent 



Special Feature 

8085 to PC-ISA 

Hard Disk Interface 



Adapting a PC/ISA card to an 8085. 

I needed a hard disk for a 8085 project. The common so- 
lution is to use a host interface and controller. However, 
boards like the WD1002HDO are becoming scarce. I con- 
sidered SCSI but I'd need a SCSI interface to drive a SCSI 
drive and I didn't have either of these either. I opted to 
look at a different source for a hard disk controller for my 
8085 board. What I was trying to avoid was complex inter- 
facing and spending money. The most obvious source was 
cheap and plentiful supply of 8bit ISA bus cards. I settled 
on the WD1002S-WX2A mostly because I had two that were 
good. They would interface to the ST225 and ST251 drives 
I have laying around. 

The question is, what does it take to talk to it? That was 
helped along when a request for information yielded an 
article interfacing the slightly smaller WD1002S-WX1 to 
an SC84 ZI80 system. The WD1002 ISA boards are inter- 
changeable for the application, the only differences being 
board size and surface mount instead of dips. The next 
step was creating a 8085 to ISA 8bit adaptor. I had sev- 
eral articles that described this in painful terms. I didn't 
need the ISA bus for general use, I just wanted a hard disk 
controller. I rejected creating a copy of the ISA bus as being 
too complex. What I wanted was the 1002HDO! The prob- 
lem was, how do I make the 1002S-WX2A look like a few 
simple ports to the CPU? 

Going to the drawing board, I pulled out one of the boards 
and started looking at it closely with the specifications that 
I had available. It was a complete controller. The inter- 
face is fully decoded, buffered and it requires a known set 
of TTL compatible signals from the ISA bus. Without sche- 
matics for the card, it was, for all intents, a black box. 
Actually this is ok since we know what the inputs and out- 
puts are and what goes on in the middle has been done for 
us. 

The 1002S-WX2A responds to a standard address for I/O 
at 320h to 323h and has Eprom at CSOOOh to C9FFFh with 
the standard jumpers in place. The control signals were 
address, MemRD/, lORD/, lOWR/, DRQ, DACK, IRQ, AEN 
and Reset. Right off, I could see that this was a subset of 
the ISA bus which cut the interface task down some. Look- 
ing at the card in hope of getting some inspiration, I no- 



ticed that on the edge connector many bus signals did not 
even have contacts. An idea, how much of the interface 
could be eliminated? First off was the Eprom at CSOOOh. 
The system has enough Eprom of it's own and clearly this 
was excess. This eliminated the MemRD\ and A 10 through 
A19. This was a start. I then looked at how to put the 
board into an eight bit address space. 



I5R 
NAME 



FUNCTION 



DMA XFER fiCTIVE 



R9 
R8 

r\7 

fiS 
fl4 
fl3 
fl2 



EN7-H 
ENS-H 
ENS-L 

EN4-L 

EN3-H 

EN2-L 

ENl-L 

EN0-L 




I/O SEL 



L06ICA. I/O SELECTION 



Figure. 1 Logical I/O selection. 

Looking at the I/O address space control lines made sev- 
eral things obvious. Addresses AO and Al are register 
selects. I guess-timated that somewhere on the board or in 
a chip the remaining eight lines enable the board for I/O. 
The likely decode is shown in the figure as the logical And 
of those eight lines, five are active low and three active 
high. We only need 6 of these lines to select an 8 bit ad- 
dress. By selecting from the available enables and forcing 
the unused two to zero or one as needed we can have the 
board appear at many different addresses. I chose to use 
the two active high and four active low to assign the board 
to COh. The remaining active low line is grounded. 

I used one of the active high lines to qualify 10 operation 
selection off the 8085 IO/M\ line. The 8085 board does 
not fully decode IO/M\, RD\ and WR\ to distinct IORD\ or 
IOWR\. The same idea could be used in a Z80 system to 
decode the IORQ\ and RD\ or WR\. I decided to connect 
the HDC reset line to the 8251 DTR\ line as a convenient 
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Figure.2 Pinout of the WD1002S-WX2 as component with interface names 
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Header file for HDC 

Assemble using DRI ASM or equivelent. 
SIM and RIM will be inserted with DB. 



SIM 


EQU 


30H 


; insert as DB SIM 


RIM 


EQU 


20H 


; insert as DB RIM 



PROTO test bed card is VtlOO Printer Buffer Card 
These are slightly 8085A. with 4k EPROM. 2k RAM, 
3 8251AS, 8116 BRG and minimal glue logic. 
Mods applied are freeing up interrupt pins. 
Supplying BRG output to all 8251s and adding 
local reset generation 

Here we keep all the important addresses for 
code and whatever. 

Memory locations: 

0000 : ROM starts at OOOOh 
lOOOH ; ROM is 4k part 
2000H ; Memory decode is 4k boundary 
0800h : RAM is 2k part 

Magik memory addresses: 

Interrupts in hardware of 8085A. The RIM and SIM 

instructions can monitor status of and mask interrupts. 

Level trigger maskable priority 4 

Level trigger maskable priority 3 

Edge trigger maskable priority 2 
non-maskable high priority 1 



ROM 


EQU 


ROMLN 


ECU 


RAM 


EOU 


RAMLN 


EQU 



INT55 EQU 


02CH 


INT65 EQU 


034H 


INT75 EQU 


03CH 


TRAP EQU 


024H 


;I0 decodes: 




P0RT51A EQU 


000 


CSR51A EQU 


OlOH 


PQRT51B EQU 


020H 


CSR51B EQU 


030H 


P0RT51C EQU 





CSR51C EQU 


050h 



040H 



data port 8251 device A 
CSR for 8251 device A 
Data port 8251 device B 
; CSR for 8251 device B 

; Data port 8251 device C 
CSR for 8251 device C 



BAUDS EQU 060H ; base address for BRG 

The low 4 bits are baud rate. 

Baud rates below 1200 left off for brevity 

All ports use same BRG! 



Name 



Address = 



baud rate 



B1200R EQU 

B2400R EQU 

B4800R EQU 

B9600R EQU 



BAUDB+12 
BAUDB+13 
BAUDB+14 
BAUOB+15 



16x 1200 

16x 2400 

16x 4800 

16x 9600 



B1920R EQU BAUDB+16 

8251A CSR Bits. 
Command bits 
ENHUNT EQU lOOOOOOOB 



I REST 

RTSF 

ERES 

SBRK 

RXE 

DTRF 

TXEN 



EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 



OlOOOOOOB 
OOIOOOOOB 
OOOIOOOOB 
OOOOIOOOB 
OOOOOIOOB 
OOOOOOIOB 
OOOOOOOIB 



16x 19200 



Not used, sync mode 
internal reset l=reset 
1 sets RTS pin to 
Error Reset l=reset 
a 1 Forces TX break 
RX enable l=enable 
1 sets DTR pin to 
TX enable l=enable 



NOMCWD EQU RTSF+ERES+RXE+DTRF+TXEN : typical CSR byte 

Note CSR51A DTR is used to control hardware reset of the HOC 
should it get lost and at power up. CSR51A must have DTRF set 
to 1 to clear HDC reset. This will be done in the general INIT 
code that sets up board level and branches to HDCinit. 



DSR status 

SYNC det, sync mode 

Framing error 

Overrun error 

Parity error 

TX empty 

RX reg has char if 1 

TX reg can accept char if 1 



; Stati 


js bi 


ts 


DSRS 


EQU 


lOOOOOOOB 


SYNDET 


EQU 


OlOOOOOOB 


FERR 


EQU 


OOIOOOOOB 


ORERR 


EQU 


OOOIOOOOB 


PERR 


EQU 


OOOOIOOOB 


TXEM 


EQU 


OOOOOIOOB 


RXRDY 


EQU 


OOOOOOIOB 


TXRDY 


EQU 


OOOOOOOIB 



and controllable single bit port. I may 
add that the DTR\ goes high at power 
on reset time so this give me a power 
on reset as well. This makes it pos- 
sible to do a software reset of the HDC. 

Further simplification was found by 
choosing to not implement DMA. This 
meant ignoring the DRQ line and forc- 
ing the DACK line to the false condi- 
tion. Data is buffered on the control- 
ler card so DMA to keep up with the 
disk is not required. I did hook the IRQ 
line to the RST5.5 line on the 8085 for 
later interrupt use because it can also 
be polled using the RIM instruction. 
This means a polled transfer. Also lines 
like AEN had to be forced to false to 
prevent spurious deselects. AEN is used 
during DMA data transactions to dis- 
able the address selection logic as the 
DMA controller does this with the 
DACK signal. I might add that lORDY 
and IOCHK\ on the ISA bus were not 
used by the board. For initial testing, 
this is easier to debug. 

See Figure 2 for the pinout of the 
WD1002S-WX2 as component with 
interface names 

The target system is something I have 
a bunch of They are printer buffer 
cards for vtlOO terminals. Their basic 
design is 8085, 4k of eprom, 2k of ram, 
3 8251 usarts with rs232 conversion and 
a single baud rate generator. This, with 
minor mods, is useful for control sys- 
tems on a card that is 4.5 by 5 inches. 
I have a simple debug monitor with 
download to use on this board. It's 
simple and general enough in design 
to use for anything. This was a suit- 
able platform to test the interface to the 
HDC. Other possibilities could have 
be 8748/9 or 8751 single component 
CPUs. The obvious use is on a CP/M 
system that needs a hard disk interface. 

The interface at this point is all me- 
chanical and interconnection to the 
8085 board. The 8085 board does not 
have a external bus but it's easy enough 
to pick up the needed signals directly 
off the 8085 and 8251. Some would 
complain that I may have exceeded the 
fanout of the 8085 but the 3mhz part 
has good output drive and fairly relaxed 
timing. The board, drive, and control- 
ler used the same power supply since 



The Computer Journal / #79 



23 



it was big enough. Testing has pro- 
gressed to the point where the interface 
responds and drive seeks were per- 
formed by poking data to the various 
ports. Programming is the next aspect 
of the project and is a later article. 

The idea that a PC ISA bus card can 
be applied to systems other than PCs 
is not new. In most cases the goal was 
to create a complete bus so any card 
could be used. While that approach has 
value, it is also fer more complex. As 
another possible application, I looked 
at a modem card and again saw a sim- 
plified interface that would lend itself 
to other applications as a black box 
component. My goal was to find a hard 
disk interface cheap. By examining a 
widely available PC hard disk control- 
ler and equating it to a large chip es- 
sentially made the board usable for non- 
PC applications. Also, there are many 
hard disk boards for ISA that appear 
the same or very similar. This would 
make replacements easier to come by. 

Allison J Parent 

<allisonp@world.std.com> 



: HDC 10: 

HDCB EQU OCOH ; base address of controller 
DATAR EQU HOCB+0 ; HDC data register bi directional 
STATS EQU HDCB+1 ; HDC status read 

: NOTE: A Write to STATS causes internal reset 
EBIR EQU H0CB=2 ; Eight bit Input, reads setup sw 

; NOTE: A Write to EBIR causes a command attention 
DMAIRQ EQU HDCB+3 : DMA and IRQ enables write only 

DMAIRQ bits 

Even though they may not be used at the bus level they must be 
enabled for status 10 via STATS read. 



DMAEN 
IRQEN 



EQU OIB 
EQU lOB 



Enable DRQ external 
Enable IRQ external 



request and status bit 
resquest and status bit 



commands are packet oriented. The host will first write to 
EBIR to force the controller to command attention for a command 
write when REQ is asserted the host will then write a multibyte 
command block via DATAR. Monitoring the status of STATS register 
is required for protocol handshake. 

HDC port read bits for STATS 

HOIRQ EQU QOIOOOOOB : interrupt request 
DMARQ EQU OOQIOOOOB ; DMA request 

BUSY EQU OOOOIOOOB ; controller is executing a command 
COSTS EQU OOQOOIOOB : Command or data 

; Indicates a data transfer <1> or status<0> 
lOSTS EQU OOQOOOIOB ; 10 direction 

; Indicates direction of transfer read if set, write if clear 
REQST EQU OOQOOOOIB ; Request 

; Controller is ready for data transfer if set 
; Host buffer 



ORG RAM 
SECBUF OS 512 



Command buffer 



at start of RAM 



Some commands allow 11 bits for cylinder address, the largest 
value allowed is 1024 (10 bits). Number of heads are limited 
to 8. Sectors per track is 17 invarient. A sector is 512 bytes. 
The largest drive is then 1024*8*17*512=71mb 



HDCMDO DB 00 

HDCMDl DB 00 

HDCMD2 DB 00 

HDCMD3 DB 00 

HDCMD4 DB 00 

H0CMD5 DB 00 



END 



Command code 

bit 5 drive, bits 4-0 head number 
bits 7-5 MSB of cylinder number 
bits 4-0 sector number 
LSB low 8 bits of cylinder number 
Sector count or interleave (command dependent) 
bit 7 retry disable, general retry 
bit 6 retry disable, ECC retrys 
bits 2-Q step rate 
000=3ms, lQ0=20Qus, 101=70us 
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Simplex III 

Parts 



Special Feature 
Advanced 



by Dave Brooks 



TTL Computer 



Simplex-ni Machine Instructions 

This is the third in a series of articles decribing Sim- 
plex-Ill, a home-designed CPU. The machine was built in 
the late 1970's, using discrete TTL parts. Simplex-Ill was 
a big-endian machine, with the least-significant byte of a 
multi-byte object at the highest address. Data width was 8 
bits, with a 64kB address space. 

The overall architecture was described in the previous 
issue. The programmer-visible registers are shown in Table 
1. These registers were implemented in a small bipolar 
RAM, the "SPAD". 



Tsbl9 1 




Name 


BytesAddress Function 


S 2 


0..1 Sequence (instruction pointer) 


XI 2 


2..3 Index / data register 


X2 2 


4..5 ditto 


X3 2 


6..7 ditto 


A 1..8 


8..F Worlcspace (accumulator) 



A typical instruction proceeds by reading the S register 
(in 2 bytes) from SPAD, incrementing it by 2, and posting 
the result back to SPAD and to the two bytes of the Store 
Address register. Two memory-read cycles follow, with the 
16-bit address register auto-decrementing each time. 

Since all instructions are 2 bytes long, this leaves the 
operation-code in the Instruction Register, and the address 
offset in the "R" register (a temporary rejgister). The 8 in- 
struction bits are broken (in most instructions) into 3 fields 
thus (recall that in big-endian notation, bit-0 is the most 
significant): 

Operation 4 bits [0:3] 

Operand register 2 bits [4:5] 

Index register 2 bits [6:7] 

The first operand is selected by the "operand register" 
bits, as A, XI, X2, or X3. The second operand is addressed 
in memory, by zero-padding the content of "R" (the address 
offset), and adding the content of the "index register" S, 
XI, X2, or X3. As before, this addresses the highest (least- 
significant) addressed byte of the operand. As the operation 
proceeds, both the memory and SPAD address registers auto- 
index. 

Relative jumps are executed in the same way, by taking 
an address forward or back relative to S, and storing that 
address in S. The 8-bit displacement is always zero-filled 
to 16 bits: an instruction bit determines whether this value 
is to be added or subtracted fi-om the S register. 



For all registers except A, the data length is fixed at 2 
bytes. A "length" register can be loaded, to define the length 
of A at anything from 1 to 8 bytes. Of course, this value 
simply defines the repeat count for operations involving A. 
The length value remains set until changed explicitly 
changed again. 

A typical instruction is: 

ADD A,X1,DATA 

where "A" is the operand, and "Xl" the address base. 
"DATA" is the address of the second operand, as an offset 
from register XI. The effect of this instruction is to add A 
(at the currently set length) and DATA, storing the result 
in A. The condition bits will also be set. 

Instruction-bytes take one of the 4 formats listed in 
Table 2. All instructions use Format 1, except for the SET 
and BC instructions. 



Table 2: Instruction Formats 

Format - Function Byte — 

1 2 3 4 5 6 7 
1. -Op-code- 



-Ro- -Rx- 

Length 

1 IT J K 
Condition Dim. 



Formats 2 and 3 are used by the SET instruction. When 
I[4]=0, the remaining bits set the effective accumulator 
length to 1..8 bytes, giving a working (integer) precision of 
8..64 bits. When I[4]=l, I[5] terminates an interrupt, while 
I[6:7] are the J and K inputs to a flipflop. This flipflop drives 
a "signal" LED as a prompt to the user. SET instructions 
ignore the address/data byte. This instruction is not used 
often enough to justify the extra logic to count S by only 
one byte, and so save the space taken up by the address byte. 

Format 4 is used by the Branch Conditional instruc- 
tion. If I[7]=0, the address offset is added to S for a forward 
branch, while if I[7]=l, the offset is subtracted, for a back- 
ward branch. I[4:6] determine the branch condition, as 
shown in Table 3. 

The machine instructions are listed in Table 4. The JI/ 
JIL instruction has a side-effect, in that if Ro=Xl, X2, or 
X3, S is stored in Ro (ie save subroutine link). If Ro=A, the 
link is discarded (ie the instruction is a simple jump). Then 
or otherwise, q => S (indirect jump). If this instruction is 
executed in interrupt level, both S registers are loaded: this 
intentional side-effect was used at boot-up to set up the in- 
terrupt vector (the interrupt-level S register) as explained 
below. 
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Subroutine return is typically done using the "MIR" 
(move & increment register) instruction. This takes a 2-byte 
register, adds a constant, and stores the result in the same 
or another register. A typical subroutine entry/exit sequence 
is listed in Table 5, where the "DP" (define pointer) opera- 
tor is defined to point 1 byte below the target instruction. 

Interrupts 

Two copies of the SPAD (and condition-code) registers 
exist, for interrupt and base-level tasks. At reset, the inter- 
rupt set are selected. Typically, the initialisation code ends 
with a JI instruction, which leaves both register-sets' "S" 
registers pointing at the same instruction. A SET instruc- 
tion then changes to base level code, which then over-writes 
the instruction at the JI target with a relative jump to the 
interrupt routine. This interrupt routine is coded as a loop, 
which finishes with a SET <base level>. The following in- 
struction will jump back to the head of the interrupt rou- 
tine. 



Hence an interrupt switches register sets, and immedi- 
ately jumps to the head of the interrupt routine. After inter- 
rupt processing is done, the SET <base level> is executed, 
leaving the interrupt level's S pointing at its successor in- 
struction, ie the jump back to the head of the interrupt rou- 
tine. Processing then resumes in the base-level registers. 



Next issue 

This article has described Simplex-III from a 
programmer's standpoint. The next article will cover the 
hardware debugging facilities. 



Table 3 


Branch-Condition Codes 


14 15 16 


Condition 





Not zero 


1 


Zero 


1 


Not negative 


1 1 


Negative 


1 


Not carry 


1 1 


Carry 


1 1 


Always 


1 1 1 


Sense switch ON (on front-panel) 



Table 5 :Typical Subroutine Entry/Exit Sequence 
SUBPTR DP SUBROUTINE 



JIL 



X2,X3, SUBPTR 



SUBROUTINE 

MIR S,X2,2 

JIL A, X3, SUBPTR 



//Point below 1st byte of code 

//Calling routine 
//SUBPTR accessible from X3 
//Link (X2) points to JIL instr. 
//Caller continues 

//Subroutine code: link in X2 

//Save X2 if reqd. 

//S « X2+2, ie return past JIL 

//As above, but link is discarded 
// (no link is ever stored in A) 



Machine Instructions 



Definitions : 



= The operand register (A, X1 , X2, X3) 

= The index register (S, XI , X2. X3) 

= Offset byte from instruction (zero extended to 1 6 bits) 

= The effective memory operand address, defined as (rx + 

= Content of Q 



I) 



Ro 
Rx 
I 
Q 

q 

Where the target of an operation is shown as "z, c" this means the C 
(condition) bits are affected, as well as loading a result into z. 



The instruction assignments are as follows: 



Code 



1 

2 

3 

4 

5 

6 

7 

8 

9 

A 

B 
C 
D 

E 
F 



Mnemonic 

ADD ro + q => ro, c 

ST ro => q 

ID q => ro, c 

XOR ro XOR q => ro, c 

AND ro AND q => ro, c 

LCP ro AND q => c 

ADS ro + q => q, c 

SUB ro - q => ro, c 

CMP ro - q => c 

JI/JILq => s 

CTS q + 1 => q, c 

SET 

RTL ro + ro => ro, c 

BC s +/- 1 => s 

LDI I => ro, c 
MIR ro + l=> rx, c 



Function 

//Add memory to register 

//Sore register 

//LD sets conditions, unlike the 8086 

//Exclusive OR memory to register 

//Logical AND memory to register 

//AND, but don't store result 

//Add register into store 

//Subtract memory from register 

//Subtract, but don't store result 

//Jump indirect/link. See text for 

side effects 

//Count in store. Always 1 -byte operand 

//Set values for operand length, interrupt terminate, etc. 

//Add to itself, ie shift left 

//Branch on conditions. Direction, and 

condition set by Ro, Ri bits 

//Load immediate, 8-bit zero-extended 

//Move/increment register. Effectively moves Ro+I to Rx 
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Adding the 16550 UART 
to a 65xx system 



by Andre Fachat 



Special Feature 

Interfacing 
6502 + 16560A 



How to add a 16S50A UART to a 6Sxx system 

I have stumbled across quite a few 6502 computers that use 
the 6551 ACIA for a serial interface. When I used this chip, 
I found it rather slow. Since I was doing a Multitasking 
operating system for the 6502, the interrupt latency became 
too large to reliably catch each and every character from 
the device even at 2400 Baud. This was even worse on the 
IMHz my C64, into which I had built an ACIA interface in 
a socket under the SID 6581 (sound chip). 

I had already heard of the 'FIFO-serial interface' for PCs, 
and even replaced some 8250's with 16550A's myself So 
I decided to replace the ACIA in my C64 with the 16550 A 
UART. 

Bus differences 

The 16550A UART chip was designed for a different bus 
than the 6502, so there are differences in how to handle the 
chip. When I had a first look at the interface, I really 
thought, 'why did they build the chip this way!'. 

The Reset line is high active - which places the chip in "run- 
ning mode" at power up, and then an explicit signal on the 
Reset line only resets tlie chip. The 65xx series use an ac- 
tive low -RESET line, such that even a simple RC-element 
with an additional Schmitt-Trigger suffices for a simple 
computer. 

The Interrupt line is high active also. You can not wire-or 
it together with other devices (brain-damaged PC design!) 
as in 65xx systems for example. (That would even work if 
the passive state would be to leave the line, and not to pull 
it down to Volts - but that's PC design...) And of course, 
there is no general clock line, but accesses take place dur- 
ing active RDAVR lines, as long as the chip is selected. The 
UART has two read (RD and -RD) and write (WR and - 
WR) lines, where each triggers a data transfer (i.e. not RD 
and -RD, but RD or -RD — which is IMHO quite peculiar, 
but I can think of uses for DMA, for example). 

These differences in the bus system are, in my opinion, the 
reason that many people still use the ACIA 6551, and not 
the much more sophisticated UART 16550A. A more so- 
phisticated chip involves more sophisticated software. In 
contrary to the simple handling of an ACIA, the UART is 
indeed more complicated to handle, which also seems a 
reason for its low usage. In fact there are many caveats in 



the UART design that make the thing terrible to program. 
See the Serial FAQ at ftp://ftp.phil.uni-sb.de/pub/people/ 
chris/The_Serial_Port {and the TCJ FTP site) for more in- 
formation. But then the UART has the already mentioned 
advantage of the FIFO, which makes it attractive. 

Schematics 

When I was rebuilding my ACIA interface to a UART in- 
terface, I had to reuse some sockets and chips, because I 
didn't really want to build everything from scratch (where 
I didn't have all the parts at home at that time anyway...) 
The old Interface card was a daugtherboard to be put be- 
tween the socket for the C64 SID chip and the SID itself 
An additional connector gave three signals: A9 to divide 
the SID address space in half (although the SID has only 
28 registers, they are mirrored in a IkByte block of I/O space 
in the C64), -E to enable the ACIA at all and -IRQ to sig- 
nal the CPU. I soldered A9 and -IRQ to appropriate places 
on the C64 motherboard, while -E goes to a switch. 

With the ACIA and the use of a dual 2-to-4 decoder 
74LS139, I was able to do the whole thing. It even made 
the ACIA disappear from the memory map, when it was 
disabled. This didn't work with the UART, because I needed 
more circuitry from the decoder to manage the RD/WR 
handling. Well, one could surely think of something cleaner, 
but I wanted it quick... 

Here's how it works in the C64 

All pins from the SID are connected from the C64 SID socket 
to the SID socket on the daughterboard, except -CS (pin 8). 
This line is or'ed with the additional A9, to remove the SID 
from the upper half of its memory window, and then given 
to the SID. The first half of the '139 then gives the condi- 
tion that Phi2 is high, -CS is active, and A9 is high. This 
output is then fed into the -E pin of the second decoder. 
The enable line (from the external enable switch) switches 
between the two used and the two not used outputs of the 
decoder. R/-W as the lower decoder address line then 
switches between the RD and the WR line. These outputs 
are or'ed with the inverted Phi2, and fed to the UART. 

This arrangements has two purposes: The two decoder stages 
that have Phi2 in the first decoder give a delay to the begin- 
ning of the access. This is needed, as the C64 switches from 
video chip memory access to CPU memory access with the 
phases of Phi2. So the address lines need some time to 
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adjust. (The VIA 6522, for example, expects the address 
lines valid at the beginning of Phi2, and doesn't work with 
the C64 that way. It needs the starting transition of Phi2 to 
be delayed.) The ORing with the inverted Phi2 then stops 
the access by invalidating the RDAVR lines when Phi2 be- 
comes inactive. This also is a reason for Phi2 being used 
as CS line. 

Another example 

I have also built a Dual UART card with two 16550A for 
my selfouilt 6502 computer, and there I used a similar ap- 
proach. I took a 74LS138, a 3-to-8 decoder. The select 
line for the I/O area goes to the decoder as enable line (- 
El), as well as Phi2 (E3). -E2 is not used and set low. AO 
is connected to R/-W of the system, and Al is another ad- 
dress line. A2 is also set low. The outputs Q0-Q3 are then 
connected to the two chips. 

-QO -> UARTl -WR 
-Ql -> UARTl -RD 
-Q2 -> UART2 -WR 
-Q3 -> UART2 -RD 

The Software 

Now that you have the UART in your computer, you have 
to have some software to use it. I have not yet rewritten the 
C64 OS to use the UART as serial interface (which I had 
done to use the ACIA before). Maybe I have this ready, 
when this issue of TCJ comes out, then you find it on my 
homepage http://www.tu-chemnitz.de/~-fachat/. But I have 
already written a generic UART device driver for my 
selfbuilt 6502 Operating System, OS/A65. 

The code shown here is part of that driver, together with a 
simple C64 binding. It actually follows the suggestions 
given in the "Serial FAQ". I have one problem, though. 
Because the interrupt generation is somehow buggy in the 
UART, the FAQ suggests to start the transmitter from out- 
side the IRQ routine. Well, in my OS I don't have any device 
code outside the IRQ routine (that is called when data is 
being sent). But then, as the 6502 cannot directly decide 
where an IRQ came from, the interrupt drivers are (almost) 
all called when an IRQ occurs, with "higher priority" first. 
So the serial driver, being the one with the highest priority, 
is called very often, even if it is not the source of the IRQ 
itself But that ensures that the IRQ routine is called and 
so I can check there, if I have to start transmission manu- 
ally. 

The listed program echos characters it receives from the 
serial line back to the serial line. It also takes characters 
typed on the C64 and sends them to the serial line. A part 
of the screen is used as character buffer, so that you can see 
something, when the program receives characters. 

I have written a SLIP (Serial Line Internet Protocol) pro- 
gram for my seUwritten OS, that uses an UART. On my 1 
MHz C64 with builtin UART it replies to Internet PING 
messages without packet loss at 9600 baud. Using the same 
program with an ACIA, even at 2400 baud, is completely 
useless due to lost characters. 



Conclusion 

The 16550A might not be the chip of choice for simple 
applications, where a high data rate is not necessary. But if 
you don't want to use the serial line as a terminal line only, 
but want to do some serious data transfer, better take an 
UART. Here you see a way to use the UART in 6502 based 
systems and how to program it. 

Andre Fachat (a.fachat@physik.tu-chemnitz.de) 



* (c) 1996-1997 Andre Fachat 

* fachat@physik.tu-chemnitz.de 
* 

* This is part of a UART 16550A serial line driver 

* for the 0S/A65 operating system. 
* 

* The 16550 is not really an easy chip, but it has 

* 16 byte input and output FIFO buffers, which 

* allows much higher Interrupt latencies. 
* 

* routines defined here are: 
* 

* devini - initializes 16550A hardware 

* devirq- must be called in the interrupt 

* routine 

* setspeed - sets the speed of the transmission 

* {yr - speed index in the divisor 

* table) 

* txon/txoff - switches transmitting on/off 

* rxon/rxoff - switches receiving on/off 



routines needed are: 

GETC 

PUTC 



- read byte from application in IRQ 
(via software FIFO) 

- write byte to application from IRQ 
(via software FIFO) 

STRCMD - get status of software FIFO 



*/ 

/* UART register definitions */ 

DLAB-0 */ 

DLAB-O */ 

divisor low, DLAB-1 */ 

divisor high, DLAB=1 */ 

Irq ID Reg, read only */ 

FIFO Control, write only * 

Line Ctrl Reg */ 

Modem Ctrl Reg */ 

Line Status Reg */ 

Modem Status Reg */ 

'scratchpad', unused */ 

/* UART is the (memory mapped) address of the UART 

* The E_* codes are distinct error codes. E_OK is 

* 0, the others are not. 

* "status" is a local variable */ 

/* status: Bit 0=1= handshake enabled 



#define RXTX 


/ 


//define lER 


1 / 


//define DLL 


/ 


//define DLH 


1 / 


//define IIR 


2 / 


//define FCR 


2 / 


//define LCR 


3 / 


//define MCR 


4 / 


//define LSR 


5 / 


//define MSR 


6 / 


//define SCR 


7 / 



1- no ACIA found 

1- set RTS hi 

1= we are transmitting (DC_SW_TX) 

1- we are receiving (DC_SW_RX) 



*/ 



//define DC_SW_RX %10000000 
//define DC_SW_TX %01000000 

/* 16550 divisor values for BAUD rates ?, 50, 75. 

* 110. 134.5, 150, 300, 600, 1200, 1800, 2400, 

* 3600. 4800. 7200. 9600, 19200 
*/ 

divisor .word 1, 2304, 1536, 1047, 857, 768, 384, 
.word 192, 96, 64, 48, 32. 24, 16, 12, 6 

/*****************************■•■********************* 

* Init UART 
* 

* This routine Is according to the Serial FAQ by 

* Chris Blum. Release IB. The FAQ is posted 

* regularly to comp. sys . Ibm. pc. hardware. comm and 

* comp. OS .msdos . programmer and can be obtained by 

* ftp at ftp://ftp.phil.uni-sb.de/pub/people/chr1s/ 
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* The_Serial_Port 

* 

* (These routines get called with the device number 

* in the x register. As this driver supports one 

* UART only, x is always - that may change) */ 



devini 



Ida #0 
sta status 



:check if there's something like an UART at all 

Idy UART+MCR 

Ida #$10 

sta UART+MCR 

Ida UART+MSR 

and #JfO 

bne nodev 

Ida #$lf 

sta UART+MCR 

Ida UART+MSR 

and #$fO 

cnp #$fO 

bne nodev 

sty UART+MCR 
; check if it has a scratchpad register 
: if not then ifs plain 8250 

Idy UART+SCR 

Ida #%10101010 

sta UART+SCR 

cmp UART+SCR 

bne dev8250 

Isr 

sta UART+SCR 

cmp UART+SCR 

bne dev8250 

sty UART+SCR 
; now check the 16xxx versions 

Ida #1 

sta UART+FCR 

Ida UART+IIR 

Idy #0 

sty UART+FCR 

asl 

bcc devl6450 

asl 

bcc devl6550 
: else devl6550A: currently only this one 
: is supported 



ok. we detected a 16550A 

with working FIFO 

Ida #%10000000 
sta UART+LCR 
Idx #14*2 : 
Ida divisor, X 
sta UART+DLL 
Ida divisor+1. 
sta UART+DLH 
Ida tfXOOOOOOll 
sta UART+LCR 



i.e. a chip 



9600 BAUD 



8N1 



Ida #7 

sta UART+FCR 
Ida #0 

sta UART+IER 
sta UART+MCR 

clc 
rts 



no FIFO enable and 
clear FIFOs, 
trigger at 1 byte 

pol led mode (so far) 
reset DTR. RTS 



nodev : no UART at all 

dev8250 : no Scratchpad, no FIFO 
devl6450 ; scratchpad, no FIFO 
devl6550 ; FIFO bug 

Ida status 

era n 

sta status 

Ida #E_N0TIMP 

sec 

rts 

/•*******•****************************************** 

* UART interrupt routine 

* 

* The interrupt routines are called one after each 

* other for every device in this OS. 

* If an interrupt source has been removed, then 

* E_OK 1s returned. E_NOIRQ otherwise. So this 

* routine even gets called, when lower level 

* interrupts occur. This is due to the single level 

* interrupt structure of the 6502 (not counting the 

* NMI, which is not really of use in this OS) 



The routine is nasty due to several reasons; The 
UART doesn't periodically generate interrupts, 
when the transmitter is empty, as the ACIA does. 
So it is possible to be able to send (i.e. put 
characters in software send FIFO) but the 
interrupt driven driver doesn't know about it. 
Therefore, the Serial FAQ suggests to start the 
transmission manually when data is written to 
the drivers internal buffers. In this OS the 
buffers (software FIFOs) are totally independent 
FIFOs (Streams) written to and read with PUTC 
and GETC. To avoid lockups, I therefore check if 
I can start sending every time the interrupt 
routine is called, even if the interrupt source 
is not the UART itself. 

The FAQ suggests checking if data is to be sent 
after all UART interrupt sources have been 
handled. But "Start transmission by simply 
calling the tx interrupt handler after you've 
written to the tx fifo [software-FIFO] of the 
program..." (These are things you can do with 
DOS.... ts.ts.ts) doesn't work here. Instead we 
check it in every interrupt call. */ 



devi rq 



i rqend 



intr 



.( 

Ida UART+IIR 

Isr 

bcc intr 
Ida #E_NOIRQ 

jmp irqe 



UART IIR 

ok, found IRQ 

no i rq source found 

not this one 



and //^OOOOOOll 
tay ; 

bne int_tx 



; interrupt mask 
four possible IRQs 



makes 



Ida UART+MSR 
jmp checkint 



int_tx 


dey 






bne 


int_rx 


tx_loop 








jsr 


tx2 ; 




jmp 


checki nt 


int_rx 


dey 






bne 


i nt_status 


rx_loop 








jsr 


rx2 : 




Ida 


UART+LSR 




Isr 






bcs 


rx_loop : 




jmp 


checkint 


i nt_stat 


us ;- 






Ida 


UART+LSR ; 


checkint 








Ida 


UART+IIR 




Isr 






bcc 


intr ; 




jsr 


nobyt ; 


i rqok 


Ida #E_OK : 


i rqe 


pha 






Ida 


UART+LSR ! 




and 


#$40 ! 




beq 


nbyt : 




jsr 


tx2 : 




jsr 


nobyt ; 



modem status interrupt 
de-locked by reading the MSR 
do it. even if this IRQ is 
not enabled. . . 



transmitter empty interrupt 
write data bytes to UART 

FIFO 



receiver interrupt 
get one char and save 



still data in UART FIFO? 



line status interrupt, 
de-locked by reading MSR 

still another IRQ pending? 



i rq sti 1 1 pending 
check if we are sti 1 1 
allowed to rx (i.e. stream 
has not been closed from 
reader) 

i rq source removed 

we get here no matter if 

UART IRQ or not 

check if we are allowed to 

start sending manually 

(THRE - LSR bit 6) 

no then end 

otherwise f i 11 FIFO 

check if we are sti 1 1 

allowed to receive (this 

ensures to check even if no 

traff i c) 



nbyt 



rx2 



pi a 
rts 



: Receive a single byte 

.( 

Ida UART+RXTX ; load data byte 
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bit status 
bpl rx2end 
jsr PUTC 
bcc rx2end 
cmp #E_SLWM 
bne test 



wh 

twl 

wl 

tx2 



txloop 



test2 



txrt 



rx2end 
inobyt 

test 

tstwater 



are we receiving? 

no, then end 

and save in software FIFO 

no error -> end 

stream below low water mark? 

this happens most and is 

caught by nobyt anyway 



rts 



check stream (software-FIFO) status 



bit status 
bpl rx2end 
jsr STRCMD 
bcc rx2end 

cmp #E_NUL 

bne tstwater 
jrap rxoff 



are we receiving? 
no -> end 

get state of stream 
ok -> end 

stream has been closed from 
reader? 

yes, then shut receiver off 



cmp #E_SEMPTY : stream is empty? 

beq wl 

tax 



Ida status 

and #1 

bne wh 

txa 

cmp #E_SFULL 

beq wh 

cmp #E_SHWM 

bne twl 
Idx #0 
jmp rtsoff 
cmp #E_SLWM 
bne rx2end 



ok. ensure that RTS is low 
we want RTS hi? 
yes, then high 



stream ful 1 

then RTS high 

stream above high water 

mark? 

; no then branch 



stream below low water mark? 
no then end 



Idx #0 : otherwise RTS low 

jmp rtson 

.) 

; Fill transmitter FIFO 

.( 

bit status ; are we transmitting? 

bvc txrt ; reading IIR should clear 

; this line 
Ida UART+MSR : are CTS and DSR ok? 
and WOOllOOOO 

cmp #X00110000 : cts or dsr inactive 
bne txrt ; yes then end 
Idy #15 : number of byte 

jsr GETC 

bcs test2 

sta UART+RXTX : send new data byte 

dey 

bne txloop : fill up FIFO 

bcc txrt 

cmp #E_EOF 

bne txrt 

jmp txoff 

rts 
.) 
.) 



we got a stream End-Of-File? 

yes, then shut transmitter 
off 



* support routines */ 



dtroff 



dtron 



rtsoff 



rtson 



Ida UART+MCR 

and #XllinilO 

sta UART+MCR 

Ida #0 

sta UART+IER 

rts 

Ida UART+MCR 

ora #100000001 

sta UART+MCR 

Ida #3 

sta UART+IER 

rts 

Ida UART+MCR 

and #%11111101 

sta UART+MCR 

Ida status, x 

ora #200100000 

sta status, x 
rts 

Ida UART+MCR 

ora #%00000010 



sta UART+MCR 

Ida status, X 

and #X11011111 

sta status, X 
rts 

/************•*•*********************************** 

* control handl ing 

* This is rather OS specific, so maybe it's not 

* necessary here. One thing to mention is, that 

* rxoff and txoff just reset their bit in the status 

* byte, rxoff then sets RTS high (rtsoff). After 

* that, both check if transmitter or receiver are on. 

* If both are shut off, then DTR is set high 

* (dtroff). 
* 

* If the transmitter or receiver are enabled, both 

* set DTR low (dtron). The receiver also sets CTS 

* low (ctslo). 
*/ 



rxon 



txon 
o2a 



rxoff 



jsr rtson 
jsr dtron 
Ida #DC_SW_RX 
bne o2a 

jsr dtron 
Ida #DC_SW_TX 
ora status 
sta status 
bne ok 



Ida status 
and #DC_SW_RX 
beq devoff 
jsr rtsoff 
; signal eof to software FIFO here 
Ida status 
and #255-DC_SW_RX 
sta status 
jmp checkdtr 

txoff Ida status 

and #DC_SN_TX 

beq devoff 
; signal close to software FIFO here 

Ida status 

and #255-DC_SW_TX 

sta status, X 

checkdtr and #DC_SW_TX+DC_SW_RX 

bne active 

jsr dtroff 
active jmp ok 



setspeed 



ok 



devon 

devoff 

onotimp 



and #%00001111 

asl 

tax 

beq ok 

Ida UART+LCR 

ora #$80 

sta UART+LCR 

Ida divisor, X 

sta UART+DLL 

Ida div1sor+l,x 

sta UART+DLH 

Ida UART+LCR 

and #$7f 

sta UART+LCR 

Ida #E_0K 
.byt $2c 
Ida #E_D0N 
.byt $2c 
Ida #E_D0FF 
.byt $2c 
Ida #E_N0TIMP 
cmp #1 
rts 
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Regular Feature 

All Users 
dBase II & TCAP 



The European Beat 



by Helmut Jungkunz 



Z-BASE - A way to use ZCPR's 
TCAP for dBASE U 

When CP/M is mentioned, one often 
hears or reads the term "standard pro- 
gram". The most popular so-called 
standard programs then were WordStar, 
Multiplan and dBASE. I always liked 
dBASE, for it offered even blunt idiots 
like me an easy interface to screen-ori- 
ented programming, even if in very ru- 
dimentary form. 

What annoyed me, was the fact, that 
dBASE had to be installed for each and 
every terminal. When ZCPR came 
about, I first thought: 

Wow - finally no more installations of 
terminals! Well, that goes for ZCPR - 
aware programs and tools only. When 
you use dBASE or any other non-ZCPR- 
program, you would still have to install 
the program first. 

One of the nice things in UNIX and in 
ZCPR is the use of a so-called TCAP 
(Terminal CAPabilities) file, that, once 
loaded, will provide a given screen en- 
vironment, usable by all applications for 
that system. 

dBASE by itself does not offer any pos- 
sibilities to directly make use of the 
ZCPR TCAP, but it has a powerful, 
built-in interface to PEEK and POKE 
memory addresses and thus to execute 
machine code! 

The theory of all that may be taken from 
the program in BOX 1. 

"CALL <memory variablO" will 
branch processing to the address speci- 
fied in a SET CALL TO <address> 
command. The address must be deci- 
mal. When you reach the called ad- 
dress, the register pair H-L points to the 
first byte of the memory variable; this 



BOX [ 1 ] -DBASPOKE.INF". 



dBASE II 2. 38 

Technical Support Note # 25 
Copyright 1983, Ashton-Tate. All 
General Distribution 



Rights Reserved 



28 Mar 1983 



Assembly code interface information 
for dBASE II 2.3B running on CP/M 2.2 . 

The syntax for PEEK, POKE, and CALL is as follows: 

PEEK( <address> ) 
POKE <address>, <byte list> 
SET CALL TO <address> 
CALL <niemory variable> 

POKE stores a list of values into a specified location in the 
computer's memory. PEEK is a numeric function that returns the value 
of a specified byte in the computer's memory. Both PEEK and POKE use 
decimal addresses and values. 

Examples: 

STORE PEEK(128) TO value 

STORE 128 TO location 

? PEEK(location), PEEK( locati on+1 ) 

* Subroutine..: LEAOZERO.LIB 

* Description.: Replaces leading blanks with 



leading zeroes. 



70, 35.126.254, 32 
54, 48. 5.194. 20 



SET CALL TO 42000 

POKE 42000. 34. 37.164 

POKE 42008. 194. 33.164 

POKE 42016. 164. 42. 37.164,201 

STORE " 123" TO number 

CALL number 

? number 

LEADZERO.ASM Replacing leading blanks with leading zeroes. 
Written by Luis A. Castro. Ashton-Tate. 1982. 



ORG 42000 
SHLD SAVEHL 
MOV 



;Load in dBASE free area. 
:Save HL registers. 
B.M ;Store length of string to counter. 



LOOP: 



DONE: 



INX 

MOV 

CPI 

JNZ 

MVI 

OCR 

JNZ 

LHLO 

RET 



H 
A.M 

DONE 

M.'O' 

B 

LOOP 

SAVEHL 



Skip to next character 
Fetch character 
Is it a space? 
Yes. done. 

Replace space with zero 
Decrement counter 
Repeat until done 
Restore HL registers. 



SAVEHL DS 



Program.: HEX-DEC.CMD 

Author..: Luis A. Castro. 

Date : 9/14/82. 7/12/83. 

Notice..: Copyright 1982. ASHTON-TATE. 

Notes...: To convert an assembled program's HEX file 
into a dBASE POKE sequence. This program works only 
with HEX dumps that look like the following: 

10A410002225A446237EFE20C221A4363005C21484 

05A42000A42A25A4C9D7 

0000000000 
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The file this program generates is a .LIB file and can 
be added to a dBASE command file using an editor 
or word-processor. 

You will need to create HEX-DEC. DBF with the structure: 



* 


HDUMMYl 


C 


001 


* 


HLENGTH 


C 


002 


* 


HADDRESS 


C 


004 


* 


HDUMMY2 


C 


002 


* 


Hll 


C 


002 


* 


H12 


C 


002 


* 


H13 


C 


002 


* 


H14 


C 


002 


* 


H15 


C 


002 


* 


H16 


C 


002 


* 


H17 


C 


002 


* 


H18 


C 


002 


* 


H19 


C 


002 


* 


H20 


C 


002 


* 


H21 


C 


002 


* 


H22 


C 


002 


* 


H23 


C 


002 


* 


H24 


C 


002 


* 


H25 


C 


002 


* 


H26 


C 


002 



SET TALK OFF 

STORE "123456789ABCDEF" TO hexvalues 

* Macros to convert hex values to decimal values. 
STORE [e($(Hlength.l.l).hexvalues)*16 +; 
e($(Hlength. 2.1). hexvalues)] TO Mhexlen 

STORE [®($(Haddress.l.l).hexvalues)*4096 +: 

e($(Haddress.2.1).hexvalues)*256 -i- e($(Haddress.3.1) .hexvalues)*16 +: 
e($(Haddress, 4.1). hexvalues)] TO Mhexaddr 
* 

ERASE 

? -CONVERTING A HEX DUMP TO DECIMAL" 

? 

ACCEPT "Enter hex file " TO filename 

IF filename=" " 

RETURN 

ENDIF 

IF e(".". filename) > 

STORE $(filename.l.®(".".filename)-l) TO filename 

ENDIF 

STORE Kfilename )-!-•'. HEX" TO infile 

STORE Kfilename)-!-". LIB" TO outfile 

ACCEPT "Enter description.." TO notes 

•? 

? "Copying structure to HEX-DEC " 

USE Hex-dec 

COPY STRUCTURE TO Hex-dec. $$$ 

USE Hex-dec. $$$ 

? "Appending from Sinfile " 

APPEND FROM Sinfile SDF 

GO TOP 

* 

* Generate the POKE sequence. 
ERASE 

SET ALTERNATE TO Soutfile 

SET ALTERNATE ON 

? [* Subroutine..: ]-^outfile 

? [* Description.: ]-i-notes 

STORE iMhexaddr TO address 

? [SET CALL TO ]-^STR{address.5) 

? [* 12 3 4 5 

[ 11 12 13 14 15] 

DO WHILE .NOT. EOF 

STORE SMhexlen TO linelen 

STORE SMhexaddr TO address 

IF linelen <> 

STORE " " TO decimals 

STORE "11" TO item 

DO WHILE VAL(item)-10 <= linelen 

STORE decimal s+","+STR(@($(H&item.l.l).hexvalues)*16; 

-H @($(HSitem, 2,1). hexvalues). 3) TO decimals 

STORE STR(VAL(item)+1.2) TO item 

ENDDO 

? [POKE ]-i-STR(address.5)-H[,]-H(dec1mals.3.LEN(decimals)-2) 

ENDIF 

SKIP 

ENDDO while .not. eof 

SET ALTERNATE OFF 

CLEAR 

DELETE FILE Hex-dec. $$$ 

QUIT 

* EOF hex-dec. cmd 



7 8 9 10]+; 



is the length byte for character strings. 
The <memory variable> must be a 
string and may not be lengthened while 
you are putting data into it. Execute a 
machine language return to get back to 
dBASE. dBASE will handle saving the 
registers. All machine memory from 
A400H up to the bottom of the CP/M 
BDOS is available, but will be over- 
written when a SORT is done. It is 
recommended that a MOVCPM utility 
be used to create protected memory ar- 
eas for assembly routines above CP/M. 

To convert an assembled program's 
hex file into a dBASE POKE sequence 
you may want to run the dBASE pro- 
gram HEX-DEC.CMD provided for you 
at the end of this documentation. 

This was released some time ago over 
the internet and tells the story. I now 
sat down and took a look at the ZCPR 
environment. Each TCAP sits in 
memory, once ZCPR has started. Con- 
sidering the latest TCAP version, the 
address of the graphic characters used 
by the terminals (GOELD) is at a de- 
fined offset of 13 from the start of 
"TCAP". "TCAP" is found at the page 
just above the Z3 environment address 
ENV. 

To find these addresses, issue from 
NZCOM or Z3PLUS the command 
ENV. This macro will peek the cone- 
sponding page of Z3ENV for your sys- 
tem. Take down the hexadecimal ad- 
dress at the left top! That is all you 
need (plus the tool ZDDTZ.COM or a 
Hex-Calculator). In my case, I have the 
address F580 for ENV. I start ZDDTZ 
and enter: 



DDTZ v2 
CPU=Z80 
-hF580 



5 by C.B. Falconer. 



(the - is the prompt, the 
rest is entered from the 
keyboard) 
F580 62848 (This is what we 

want - the decimal form of 
the address! ) 
'^C 
A:> 
(done) 

Now we take down 62848 on a piece of 
paper. We use ZDE to edit our dBASE 
"TCAP. CMD" and enter this decimal 
address as the value for ENV. Every- 
thing else is calculated automatically. 

Now bring up dBASE and issue the 
command: 

DO TCAP 
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The screen will be erased and after a 
while, GOELD will appear at the top 
of your Monitor, followed by a colon 
":". This is called by a fake "Strike- 
any-key-when-ready" conunand — > 

accept to dummy 

You may leave this out, but for debug- 
ging purposes, I think it is a great help. 
Once you strike your "ANY" key (okay, 
bad joke), the graphical characters from 
your extended TCAP will be displayed. 

If you have an idea, how the HEX-TO- 
DEC routine shown here can be used 
to immediately return the ENV address 
in decimal to dBASE, I would certainly 
appreciate this. 

Just to be complete, I also include a 
dummy extended TCAP, that can be 
used on all non-graphical terminals to 
use standard characters like "+",".","!" 
and so on. 

This is an example, of how a Televideo 
terminal with no graphical characters 
may be turned into a "Graphical Ter- 
minal". This is a legal hoax that works 
nicely to convince ZCPR, your termi- 
nal can do it. And as a matter of fact, 
it does. 

Regards from Germany 

Helmut Jungkunz 
helmut.jun^nz@metronet. de 



BOX [ 2 ] 



TCAP.CMD 



♦Routine TCAP.CMD by Helmut Jungkunz, ZNODE 51, Germany 

erase 

store to count 

*hex TO dec CONVERSION routine NEEDED 

* Here I enter the address of my Z3ENV in decimal manually 

* to get this address, issue the command ENV from NZCOM or Z3PLUS 
store 62848 to ENV 

store (ENV+128) to ENV 

store (ENV+13) to GOELD 

? "GOELD =•', GOELD 

*the nect line is a "wait for any key pressed ..." 

accept to dummy 

store GOELO+17 to count 

store count+16+peek(count) to count 

store chr(peek(count) ) to UL 

*UL is Upper Left of a box 

? count, UL 

store (count+1) to count 

store chr(peek(count)) to UR 

*UR is Upper Right of a box 

? count, UR 

store (count+1) to count 

store chr(peek(count)) to LL 

*LL is Lower Left of a box 

? count, LL 

store (count+1) to count 

store chr(peek(count)) to LR 

*LR is Lower Right of a box 

? count, LR 

store (count+1) to count 

store chr(peek(count) ) to HL 

*HL is Horizontal Line of a box 

? count, HL 

store (count+1) to count 

store chr(peek(count)) to VL 

*VL is Vertical Line of a box 

? count, VL 

store (count+1) to count 

store chr(peek(count)) to FB 

*FB is the character Full Block 

? count, FB 

store (count+1) to count 

store chr(peek(count)) to HB 

*HB is the character Half Block 

? count, HB 

store (count+1) to count 

store chr(peek(count) ) to TI 

*TI is the character Top Intersection 

? count, TI 

store (count+1) to count 

store chr(peek(count)) to BI 

*BI is the character Bottom Intersection 

? count, BI 

store (count+1) to count 

store chr(peek(count)) to MI 

*MI is the character Middle Intersection 

? count, MI 

store (count+1) to count 

store chr(peek(count)) to RI 

*RI is the character Right Intersection 

? count, RI 

store (count+1) to count 

store chr(peek(count)) to 

*LI is the character Left 

? count, LI 

store (count+1) to count 

enddo 

end of TCAP.CMD 



LI 
Intersection 



BOX [ 3 ] DUMBTERM.Z80 



; Z3TCAP fi 
ESC EQU 



le: Z3TCAP.Z80 
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Escape character 



The first character in the terminal name must not be a space. For 
Z3TCAP.TCP library purposes only, the name terminates with a space 
and must be unique in the first eight characters. 



TNAME: DB 'TVIDUMMY 
GOFF: DB GOELD-TNAME 



; Name of terminal (13 chars) 
Graphics offset from Z3TCAP start 



Terminal configuration bytes B14 and B15 are defined and bits 
assigned as follows. The remaining bits are not currently assigned. 
Set these bits according to your terminal configuration. 
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B14: 



B14 b7: Z3TCAP Type = Standard TCAP 1 = Extended TCAP 



bit: 76543210 
DB lOOOOOOOB 



Configuration byte B14 



B15 bO: Standout = Half -Intensity 

B15 bl: Power Up Delay. = None 

B15 b2: No Auto Wrap... = Auto Wrap 

B15 b3: No Auto Scroll. = Auto Scroll 

B15 b4: ANSI = ASCII 



= Reverse Video 
= Ten-second delay 
= No Auto Wrap 
= No Auto Scrol 1 
= ANSI 



B15: 



bit: 76543210 
DB OOOOOOOOB 



Configuration byte B15 



Single character arrow keys or WordStar diamond 
OB 'K'-40H ; Cursor up 
OB 'V'-40H ; Cursor down 
OB •L'-40H ; Cursor right 
DB •H'-40H ; Cursor left 

Delays (in ins) after sending terminal control 
strings 

DB : CL delay 

DB : CH delay 

DB ; CE delay 

Strings start here 



CL 
CM 
CE 
SO 
SE 
TI 
TE 



DB 
OB 
OB 
OB 
OB 
OB 
OB 



'Z'-40H.O 
ESC.'=^-^ %+ 
ESC'T'.O 
ESC. '64'. 
ESC. 'GO', 
ESC. 'GO'. 
ESC. 'GO', 



.0 



Home cursor and clear screen 

Cursor motion macro 

Erase from cursor to end-of-line 

Start standout mode 

End standout mode 

Terminal initialization 

Terminal deinitial ization 



LD 
LI 
CO 



Extensions to standard Z3TCAP 



OB 
OB 
OB 



ESC.'R'.O 
ESC.'E'.O 
ESC.'Y'.O 



Delete line at cursor position 
Insert line at cursor position 
Erase from cursor to end-of-screen 



The attribute string contains the four command characters to set 
the following four attributes for this terminal in the following 
order: Normal. Blink. Reverse. Underscore 

Set screen attributes macro 
Attribute string 
Read current cursor position 
Read line until cursor 



SA: 


DB 





AT: 


OB 





RC: 


OB 


ESC.'?'.0 


RL: 


OB 






; Graphics TCAP area 
60ELD: OB 



Graphics On/Off delay in ms 



Graphics strings 



GO: 
6E: 
COO: 
CDE: 



OB 
OB 
DB 
DB 



ESC. 
ESC. 



'H'-40H,0 
'H'-40H.0 
'.O'.O 
'.3'.0 



Graphics mode On 
Graphics mode Off 
Cursor Off 
Cursor On 



Graphics characters 



GULC 

6URC 

6LLC 

GLRC 

GHL 

GVL 

GFB 

GH6 

GUI 

GLI 

GIS 

GRTI: 

GLTI: 



DB 
DB 
DB 
OB 
06 
DB 
DB 
DB 
DB 
DB 
06 
06 
06 



'-I-' 
'-I-' 

' + ' 



Upper 1 
Upper r 
Lower 1 
Lower r 
Horizon 
Vertica 
Full bl 
Hashed 
Upper i 
Lower i 
Mid int 
Right i 
Left in 



eft corner 
ight corner 
eft corner 
ight corner 
tal line 
1 1 ine 
ock 
block 
ntersect 
ntersect 
ersect 
ntersect 
tersect 



Fill remaining space with zeros 

REPT 128-($-TNAME) 
06 
ENDM 

END 

• End of Z3TCAP 
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Regular Feature 

68xx/68xxx Support 

C & Assembly 



Small System Support 

by Ronald W. Anderson 



C Class Notes 8, Address Program in C 

This time let's digest a typical short program in C and see 
just how it works. The program reads a data file of names 
and addresses (and other information if desired) and prints 
each record that contains a string that matches the string 
given on the conmiand line. It ignores case. If I give it the 
command: 

address jones 

It will print all the records containing "jones" or "Jones" or 
any combination of caps and lower case. It doesn't just 
print the line but the whole record. The data file is simply 
a text file that can be edited with any editor. Records are 
entered just as they will appear in the printout: 



* John Jones 1234 5th st. 
Phone: (000) 111-2222 



Elko NV 78901 



The program will list any record that has a match to the 
search string on the command line. For example it would 
match the above record to "elk" or "nv". Let's look at the 
program and then go over it line by line. This program has 
been left in the style of ANSI C with function prototypes 
and function arguments defined in this new style. 

/* address progran in C - uses data file of name 

and addresses with records separated by lines 

with asterisk in the first column. Matches a 

search string and prints each record that 

contains the string. */ 
#include <stdio.h> 
#define TRUE 1 
#define FALSE 
// function prototypes 

int read record ( void ) ; 

int BatcH{char *Batchbuf); 

int ch; 

char recbuf[6001; 

FILE *infile; 
void main(int argc.char **argv) { 

if (argc —1 ) 

puts('address needs a string to match"); 

- ((infile - fopen("c: \\addr.dat", "r"))" NULL) 



// 
// 
// 



if 
{ 

}. 



puts{"can't open address data file\n°); 
exit(1); 



the next line is the main loop of the program. 
It calls the two functions in turn, uses the 
results to produce an output and loops until 
// the end of the data file 

while (read_record()) if {match(argvl1] )) 

puts(recbuf ); 



fclose(infile); 
exit(O); 

// this function gets a record in recbuf and 
// returns TRUE until end of file is detected at 
// which point it returns FALSE, 
int read_record(void) { 

int k-0; 

while ((ch -getc(infile) ) != '*') 

if (ch -= EOF) return FALSE; 
recbuf [k++J=ch; 

recbuf[kl =0; 
return TRUE; 
} 

// this function searches recbuf for a match to the 
// search string and returns TRUE if it finds one, 
// otherwise returns FALSE 
int match (char *matchbuf) { 

int m"0,r=0; 

while (recbuf [r]) 

while ( tolower( recbuf [r++] ) == 

tolower(matchbuf [m++] )) 
if (matchbuf [m] == 0x00) return TRUE; 
m «0; 

return FALSE; 
} 

You might think this is a very short program for what it 
does. It makes rather full use of the shortcuts available in 
C. It combines asignment statements and function calls. It 
uses function call returned values in tests. 

You might note that the data file path and name are hard 
coded into the program, so you must use the filename 
addr.dat and it must be in your c:\ directory (i.e. the root 
directory). You can hard code a different name or path if 
you wish. 

Note that we put the main() function first. This is more in 
line with standard C programming practice. The gurus all 
say that main is really an outline of your program calling 
out the various functions in order, and if you are to do top 
down programming, you should start there. You can block 
out the called functions to be empty, i.e.: 

void function { } 

Now you can write the functions one at a time and test them, 
perhaps with a lot of print statements in the fiinction or in 
main() to test the operation of the function. 

While all this sounds good on paper, speaking from expe- 
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rience, I can say that main() by the time I am done, doesn't 
resemble main() that I started with! As I look at each 
function I get ideas for improvements and main() changes 
accordingly. That doesn't, however, make the approach 
wrong or invalid. It is always a good idea to block out a 
program before working on the details. Advocates of top 
down programming would simply say that I don't spend 
enough time in the planning stage. I start coding too soon. 
I would counter that I could spend a very long time plan- 
ning and my code still would require debug. 

I sometimes violate this rule if I know that one function in 
the program is going to be particularly difficult. I might try 
to do that one first, doing only a dummy main program that 
calls it and allows testing of it. Later when the hardest part 
has been debugged, I'll go back and finish main and Uien 
fill in the other, hopefully easier functions. 
Well, this has not been a complete item by item discussion 
of C, but over the last year and a quarter, we have covered 
the main features of the C programming language. Hope- 
fully at least, this has been done in a way that will allow you 
to continue with a good textbook on C to learn more. 

Whether you have a very small C, one of the dialects of the 
original Small C, or something more complete like Borland 
Turbo C or Microsoft Quick C, you will find the differences 
small. The Small C versions don't have float or double data 
types, but you can do all of the things we've done in this 
series. That is, you can manipulate files and do integer 
arithmetic quite nicely. If you are running a 6809 with 
FLEX you might be able to find a copy of Windrush C by 
James McCosh. It has float and double data types and it is 
not super complicated or large out of line with the resources 
of a 6809. If you find a later version it will include my 
scientific function package that I wrote for it and gave to 
James. If you get an earlier version and want the "scipack" 
package, let me know and I'll send it to you. I have new and 
improved sci function algorithms done since then. 

If you are an old time reader of '68' Micro Journal you 
might remember a product called "Duggers Growing C". I 
was asked to review it way back when, and I found bugs by 
the dozen. I had access to the source code (in 6809 assem- 
bler) of the runtime library and was able to fix a number of 
bugs, but I couldn't review the thing and give it a "thumbs 
up", nor could I fix bugs in the compiler proper, since I 
didn't have source code. I am not talking about bugs in that 
the compiler didn't meet the then standard (actually one 
didn't exist then), but just plain operational errors, particu- 
larly in the math package. 

At the time I offered indirectly to fix it for Duggers. I talked 
to them and they said "Well, we wrote, compiled and ran a 
few programs and they ran fine". I guess if that was the 
extent of their testing, I don't wonder why it was buggy. 
They did some dumb things, for example testing a 16 bit 
integer for zero by summing the two 8 bit parts of it. Any 
value whose upper and lower bytes were 2's complements, 
like for example, 0000000 1 11111111 (byte values decimal 
1 and -1 in signed arithmetic) when added would produce 
8 zeros plus a carry and the carry was ignored so this 
number and a lot of others tested true for zero! Of course the 
bytes should have been ORed so that a 1 in any position 



would show up in the result and test non zero. I spent a 
month of evenings fixing numerous such errors and sent 
Duggers my result. I received a phone call thanking me for 
my efforts on the runtime package. Though I offered to 
work on the compiler proper for a copy of the source code, 
my offer was turned down and the ad was dropped from 
'68'. 

If you have questions, feel free to write. I am still by no 
means an expert in C, but I can find answers to most 
questions and would be happy to do so. In the past few 
weeks I've helped three other programmers with answers to 
questions about C. I think I am past the beginner stage at 
last. 

Assembler 

Let's look this time at some of the more interesting instruc- 
tions in the 6809 set. For starters how about the MUL 
instruction. It multiplies the value in the A accumulator by 
the value in the B accumulator yielding the product in the 
D accumulator. 

LDA #5 
LDB #6 
MUL 

The D accumulator now contains: 0000000000011110 
This is of course the value 30. If you know that the result 
is not going to be larger than 8 bits you can consider the 
answer to be in the B accumulator, i.e. just the 00011110 
part of the above. The problem with a multiply is that the 
result can be so large as to require twice as many bits to 
represent it. 

The beauty of this instruction is that it takes 12 clock cycles 
and is much faster than the add and shift method that would 
have to be used otherwise to multiply two 8 bit integers. It 
is left to the user / programmer how to interpret the result. 
Assuming unsigned bytes works best or at least is easiest to 
keep track of You can assume integer multiply in which 
case the binary point is at the right end of the result, or you 
can assume fractional multiply in which case the result 
must be shifted left one place and the binary point is at the 
left end of the result. You can handle signed arithmetic by 
negating negative numbers and keeping track of the sign, 
re-negating the result if the sign is calculated to be nega- 
tive. It is a pain for all but the simplest uses, but it can be 
useful. For example a compiler writer might use it to 
calculate the offset to the location of a byte or integer in a 
two dimensional array as the starting location plus the 
product of the two array subscripts (times 2 for an array of 
16 bit integers). It is my belief that some of the less 
common instructions in the 6809 set were included for 
writers of compilers to use. 

I might mention here that the 68000 instruction set includes 
both an integer and a fractional multiply called IMUL and 
FMUL to handle some of the above details for you. It also 
includes a DIV instruction which the 6809 does not. 

I thought it strange when I first saw the 6809 instruction set 
that it didn't have more instructions that would work on the 
D accumulator. It has complement and shift instructions 
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for A and B but not for D. For your thought I offer some 
subroutines to do some of these instructions. 

COMD COMA 

COMB 

RTS 
NEGD COMB 

COMA 

AODD #1 

RTS 
ASLD EQU * ;This is a way of giving a subroutine 
; two nanes 

LSLD ASLB 

ROU 

RTS 
ASRD ASRA 

RORB 

RTS 
LSRD LSRA 

RORB 

RTS 

We probably haven't discussed the difference between Arith- 
metic shifts and Logical shifts. There is no difference when 
the shift is to the left. A Zero is shifted into the low order 
bit: 

LDA #1 
ASU 
or LSLA 
result: 00000010 

The 1 has shifted one place to the left. 

Shifting to the right is different, however. The reason is 
signed arithmetic. When a register contains a signed value, 
the leftmost bit is the sign bit. When a negative number is 
divided by 2 the sign bit must be preserved, thus: 

1111110 (-2) 

shifted right one place (ASR) 
11111111 (-1) 

The value has correctly been divided by 2. If we didn't 
preserve the sign bit as in the LSR instruction, the shifted 
value would be: 

01111111 or 127 

If we are dealing with signed numbers we need to use the 
ASR instruction but if we are dealing with something like 
a bit mask we probably want to use the LSR. For example, 
here is a code fragment to fmd the highest bit that is a 1 in 
a byte value: 



FIND 


CLRA LOOP 
BEQ D0NE2 
LSRB 
INCA 
BRA LOOP 


CMPB 


#0 


D0NE2 


DECA 
RTS 






A call to FDvfD would be: 




LOB VALUE 






BSR 


FIND 







all the bits have been shifted away, counting the shifts. If 
the VALUE happened to be we get -1 back indicating an 
error. If the value is 1 A is incremented to I for the single 
required shift but the DECA instruction makes it again 
which is correct because the low order bit (bit 0) was the 
only one on. Though this might look like a contrived 
example, I assure you I have done things like this in the 
past. 

Saving and Restoring Registers 

There is a trap you can get into very easily using assembler. 
Suppose you are going along in some code and have values 
in both accumulators but you want to go to a subroutine and 
do something else. If the subroutine needs to use the 
accumulators to do its thing, the values in A and B that you 
had in your main program will be lost. 

Most of us write subroutines so they save the values from 
whichever registers they are going to use, and restore these 
values on exit. The easiest way to do this is to use the 
system stack and the PSHS and PULS instructions. 
Subroutine: 

NAME PSHS A,B 

instructions using A and B 

PULS A,B 
RTS 

Of course if you do this you can't return values in A or B 
(or D). You must return results in a variable somewhere or 
perhaps in the X or Y registers. 

The use of PSHS and PULS instructions requires some great 
care. Remember that the return address for the subroutine 
is on the stack. If you Push more bytes than you pull or vice 
versa, the return address will be corrupted and the program 
will go off into the wild blue and lock up or start executing 
garbage! 

These are some of the hardest bugs to find and some of the 
easiest to introduce in a program. Not saving and restoring 
the contents of a register that needs to be saved is also a 
hard bug to fmd in an assembler program. 

Had you not guessed, PSHS and PULS instructions are 
followed by a register list. You can save one register or all 
of them. The order of the list is unimportant. The proces- 
sor handles the order so they don't get scrambled by the 
process. 

Of course with multiple instructions you can reverse the 
order and effectively swap the contents of two registers: 

PSHS A 
PSHS B 



PULS A 
PULS B 



On return, A contains the number of the highest order bit 
that was a 1. Bits are counted right to left, the lowest order 
bit being bit and the highest being bit 7. The algorithm 
is to shift the value until the remaining value is zero, when 



This will SWAP the contents of A and B. You must PULL 
the last thing you PUSHed first. If you DON'T want to 
swap you must do it this way: 
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PSHS A 
PSHS B 

puls'b 

PULS A 

If you just want to swap two registers the EXG instruction 
can do that: 

EXG A,B 
EXG X,Y 

If you want to copy the contents of A to B or X to Y you use 
the TFR instruction: 

TFR X.Y 
TFR A,B 

This leaves the contents of the first (source) register intact 
and copies it into the second (destination) register. Note 
that for either of these instructions the registers to be ex- 
changed or those involved in the TFR must be the same 
size. You cant EXG A,X. The assembler will flag this error 
for you. 

We ought to discuss the logical AND and OR instructions. 
First let me say that the operations such as ADD, SUB, 
AND, OR, EOR etc. all leave the results in the register that 
is being used. 

LDA #5 
ANOA #$FE 
five - 00000101 
$FE - 11111110 
RESULT - 00000100 

The AND result is left in A after the execution. The effect 
of an AND is to turn individual bits OFF. Since our 
"MASK" had the low order bit off, the result would be to 
make the contents of A an EVEN number because we have 
turned the I's bit off. 

LDA #15 

ORA #$10 

15 - 00001111 

$10 - 00010000 

RESULT- 00011111 

The effect of the "MASK" in the case of the OR is to turn 
individual bits ON. 

The AND instruction can be used to see if the contents of 
A or B have a particular bit ON: 

MASK EQU $04 00000100 
LDA VALUE ANDA MASK BNE ... 

Whatever VALUE happens to be, the branch will be taken 
if bit 2 is a 1 and will not be taken if bit 2 is a 0. 

There is a test that doesn't destroy the contents of the 
accumulator. It is the BIT instruction 

Suppose in the above example VALUE = 7 After the AND 
instruction A would contain 4 because we have ANDed 
away the other bits. 

LDA VALUE BITA MASK BNE ... 



The result is the same as in the previous case where we used 
AND, EXCEPT that A now still contains the original value 
of 7. 

The effect of the BIT insruction is to AND the MASK or 
whatever with the contents of A but NOT to write the result 
into A. We could do multiple tests in a sequence without 
having to reload A with VALUE again: 

LDA VALUE BITA #$80 BNE SEVEN BITA #$40 BNE SIX ... 

We could test each bit with a different value to find the 
highest order bit that is on, as in one of the examples above. 
This obviously is the hard way to test all 8 bits of a byte 
value, but if we only wanted to test two or three, it might be 
fast and short. 

There is a similarity in the situation of the SUB and The 
CMP instructions. We could test for A containing the value 
17 a couple of different ways 



LDA VALUE 
SUBA #17 
BEQ ... 



(assume 17) 



We would branch if the value is 17 because the subtract 
would make the contents of A zero. The condition code 
register zero bit would be set. The BEQ instruction looks 
for the zero bit to decide whether the EQUAL condition is 
true. 

LDA VALUE 
CMPA #17 
BEQ ... 

This does exactly the same thing. The CMP instruction 
subtracts the inunediate value and the BEQ test checks the 
zero bit of the CCR, which is set as the result of the CMP. 
The difference is that the value in A remains 17. That is, 
the result of the subtraction is not written back into A. 

General 

I've recently been given an almost antique 286/12 computer 
to play with. A friend of mine wanted to upgrade his 
computer that was considered quite a machine in 1988 
when he bought it. It has a 360K 5.25 inch floppy drive, a 
1.44 Mbyte 3.5", 640K of memory, a 145 watt power sup- 
ply, a 40 Mbyte hard drive (IDE), and a reasonably nice AT 
style keyboard. It also had an EGA display board. 

We decided after a good look that about the only parts of 
any value for an upgrade would be the keyboard and the 
1.44 Mbyte floppy drive. He decided he might as well buy 
a new one and told me to keep it with an eye toward giving 
it to someone or some organization who might be able to use 
it. Yes, things surely do get obsolete quickly. The sad part 
is that the computer runs fine. With the addition of an old 
VGA board, and by plugging my monitor and mouse onto 
it, I checked it all out and loaded some software on it. It 
works flawlessly except that it is about 15 times slower than 
my present 486 system. If I needed only a fairly simple word 
processor system, I could have one very inexpensively with 
a computer like this as a start. Actually it would work 
admirably for what I am doing right now, using it as a 
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simple word processor to write this column. If I wanted 
more storage, I would probably only add a larger hard drive 
and some more memory. The motherboard has four simm 
sockets so it looks as though I could add up to 4 Mbytes, 
though there is no documentation and it might be a problem 
to get it all nmning again. 

My present system is most likely 2 to 3 times slower than 
the new pentium systems hitting the market currently. I've 
always been happy with a computer until I've used a faster 
one for a short while. The old 6809 system used to be great 
fun to use. Now when I compile a program and have to wait 
five minutes, I writhe in the pain of boredom. I can compile 
the equivalent program on my latest computer in a few 
seconds. 

When I started using 68000 based systems with real MFM 
hard drives, I was in heaven. Those 5 or 10 minute compiles 
could be done in 2 or 3 minutes. Hard disk data transfer, 
while vastly faster than with floppy drives, was still a bit 
slow. 

The 286 based system I bought (12 MHz) seemed to be a 
whiz until I got my hands on a 386-40. Then came the 486 
system. Each time, as I said, a few days use of the newer and 
faster system made the old one seem like it had been filled 
with molasses! Actually, my 486SLC50/2 is built on a 
motherboard that will accept and run a 66/2 as well. The 
clock frequency is changed by moving one jumper. Just for 
fun I decided to try running the processor (clearly marked 
as a 50 MHz one) at 66. It worked fine. Someone at work 
reminded me that the 66 version of this board has a heat 
sink on the processor chip. I switched back to 50 tempo- 
rarily and went and bought a heat sink with fan for $10 at 
the local computer store. I put it on top of the processor 
with some heat sink compound between, and anchored it in 
place at the comers with a little hot glue dribbled from 
comers to circuit board. I discovered that the hot glue 
didn't bond very well to the board and later added some 
clear silicone to hold the assembly together. I might ex- 
plain that the heat sink was intended for a 486DX and thus 
didn't just clip in place. I noted and appreciated the speed 
increase of 4/3. 

The best data transfer rate I saw on the 68000 system was 
about 90 Kbytes per second from its MFM hard drive. My 
present system hits 1,250,000 bytes per second. Loading an 
editor or a compiler is VERY fast. Now the computer does 
something and waits for its next instraction from me rather 
than the other way around. 



Though the new computers are great and I wouldn't trade 
mine for something slower when I use it for program devel- 
opment or word processing using Windows TruType fonts 
and printing in graphics mode, there are numerous reasons 
why I would rather play with the old 6809 or 68000 system 
when I don't need the speed. The biggest reason is the 
simplicity of the old computers (and the software that mns 
on them). I have found that I can mn versions of that old 
software on the new machine and it mns like lightning. For 
example my screen editor that I wrote years ago for the 6809 
system is now nmning in a new and improved version 
(translated from PL/9 to C) with more features on the PC. 
WordStar for Windows takes a full minute to fire up. It 
must for some reason completely obscure to me, have to 
read 100 disk files before it can mn. My old PAT editor 
loads as fast as I can type the command and get my finger 
on and off of the ENTER key. The .exe file is right around 
50K of code. I suspect with Windows and WordStar mn- 
ning, I am using most of the 4 megs of RAM I have on the 
PC system. 

You've seen over the past several issues how programming 
in Assembler is done. It looks (and is) rather easy for a 
small program, say a utility program. When programs get 
really large, one appreciates a faster computer. Our com- 
pany has been using the 6809 for about 12 or 13 years now. 
We never found it inadequate to perform its intended pur- 
pose UNTIL our programs grew to the point that we were 
crowding the memory limit. Then it began to be a headache 
to try to squeeze code into the 48K or so that we could use 
for program code (We need some stack space and the I/O 
uses a bit of the memory address range). 

Our reason for moving on was NOT the lack of capability 
of the small processor, but the lack of availability of suffi- 
cient memory for some of our larger applications. We began 
using multiple computers in some of our products, etc. The 
use of one of the new computers has given us a huge 
memory space, and a vast improvement in performance 
which we didn't know we needed until we had it. By that I 
mean that all the extra computing power has brought to 
mind things that we can do in our computer that we wouldn't 
have thought of earlier. 

I guess the bottom line is pretty much the philosophy of The 
Computer Journal. If you need to do something complex 
use the latest 80X86 based 100 MHz computer. If you want 
to leam something about how computers work, go get an 
old microcomputer and dig in! 
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The TC J Store 



Regular Items 



Back Issues See page 44 

All Back Issues of TCJ are available. 

TCJ Reference Cards $3.00 + $1 S+H 

So far, all we have Is the Z80 Instruction Set card from 
Issue #77. These are on heavier stock than the one sent 
with the issue. 

The next two items are Group Purchase Items. TCJ 
doesnl have the resources to stock these for you, so we 
have to collect a minimum number of orders before we can 
provide these. 

*GIDE kits $73 

Tilmann Reh's GIDE board was featured^ several is- 
sues of TCJ. It is a 'Generic' IDE boar^j^OVhe Z80 that 

ck into the 
'rs kit. Sample 
TCJ are pro- 
BIOS routines. 



plugs into the Z80 socket (you pju 
GIDE board). This is still an 
code and docs includin 
vided, but you have tc^rif\y 




cp/M cD-Roiw/r:\Va,^T:. $25 + $4 s+h 

This is tJpr^Vl^lnil Yreek CP/M CD-ROM (normally 
$39.95+!fcWTy>Wri 9,000 files from Jay Sage, David 
McGlone, S£i€ (First Osborne Group), the Beehive BBS, 
the Enterprise BBS, ftp.demon.uk, and the SimTel20 
CP/M collection from the Internet. 



Special Items 



We currently have two each of Tilmann Reh's CPU280 
boards and the IDE boards that go with them. The 
CPU280 was featured as the Centerfold in Issue #77 and 
the IDE interface was in Issue #56. These are bare boards 
and are not for the faint of heart. They are expensive and 
the parts are hard to get. But they're fast. 

•CPU280 bare board $150 

Comes with docs and utility disk. 
•IDE bare board $ 65 

Comes with docs. 
•CPU280 & IDE together $200 



CP/M Kaypro Catalog 

TCJ has taken over Chuck Stafford's Kaypro business. Here's 
our current catalog. 

Upgrades 

Advent TurboRom 

K4-83 $35.00 

K10-83 $35.00 

Kx-84 $35.00 

MicroCornucopia Roms 

Pro 8 $35.00 

884 Max $35.00 

884 Max (Lo) $35.00 

Character ROM $35.00 

Add-ons 

HandyMan $75.00 

Disk Drives 

Dual Density TEAC FD-55BV $15.00 

Quad Density TEAC FD-55FR $15.00 

□ air $PS 00 

sT-225 20 MByte mfmhd"!!!!!!!!!!!! ?? 

Disk Controllers 

WD-1002-05 HDO $75.00 

Tech Data 

Kaypro Technical Manual $25.00 

Microcornucopla Schematics with 
Theory of Operation 

K-ll/4 83 $15.00 

K-10/83 $15.00 

AII-84 $1 5.00 

Any two $25.00 

All three $30.00 

Software 

Advent Harddisk Formatter $25.00 

TurboRom Applications Patches $10.00 

TurboRom Developers Diskette $10.00 

Kaypro 10/83 Tinker Kit $10.00 

Kaypro 2,4/84 Tinker Kit $10.00 

Kaypro CP/M 2.21-1 Autoload set 

8 diskettes for K-10/84 $40.00 

Other Stuff 

Keyboards $30.00 

Video - CRT and board $40.00 

Kaypro Carrying bags $75.00 

Kaypro machines 

K-ll, K-2, K-4, K-10 available in various condition. 



TCJ can accept credit card orders by phone, fax, or mail 
or you can place an order by sending a check to: 

The Computer Journal 

PO Box 3900, Citrus Heights 

CA 95611-3900 

Phone: 800-424-8825 or 916-722-4970 

Fax 916-722-7480 / BBS 916-722-5799 

Include your shipping address with your check, and your 
internet address if you have one. For more info, contact 
TCJ via E-mail at tcj@psyber.com 



* In Europe and particularly Germany, contact Tilmann 
Reh for a current price and shipping. His email address is: 
"TILMANN.REH@HRZ.uni-siegen.d400.de'' 

His postal address is: 

Tilmann Reh 

Autometer GmbH 

Kaenerbergstrasse 4 

57076 Siegen (optional "-Weidenau") 

GERMANY 
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Regular Feature SUPPORT GROUPS FOR THE CLASSICS 
Contact Listing 



TCJ STAFF CONTACTS 



TCJ Editor: Dave Baldwin, (916)722-4970, FAX (916)722- 

7480 or TCJ BBS (9 1 6) 722-5799 (use "computer", "journal", 

pswd "subscriber" as log on). Email: tcj@psyber.com,. 
TCJ Adviser: Bill D. Kiblw, PO Box 535, Lincoln, CA 95648, 

(916)645-1670, GEnie: B.Kibler, CompuServe: 71563,2243, 

E-mail: kibler@psyber.com. 
32Bit Support: Rick Rodman, 1150 Kettle Pond Lane, Great 

Falls, VA 22066-1614. Real Computing BBS or Fax: +1-703- 

759-1169. E-mail: ricker@erols.com 
Kaypro Support: Charles Stafford, on the road somewhere. 

Email: QS 73664,2470 (73664.2470@compuserve.com). TO 

has taken over Chuck's Kaypro parts and upgrade business. 
S-100 Support: Herb Johnson, 59 Main Blvd. Ewing. NJ 086 1 8 

(609)771-1503. Also sells used S-100 boards and systems. E- 

mail: hjobnson@pluto.njcc.com. 
6800/6809 Support: Ronald Anderson, 3540 Sturbridge Ct., 

Ann Arbor, MI 48105. 
Z-System Support: Jay Sage, 1435 Centre St. Newton Centre, 

MA 02159-2469, (617)965-3552, BBS: (617)965-7046; E- 

mail: Sage@ll.mit.edu. 
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West, Hamilton, ONT, L8S ICO, Canada, E-mail: 

bj@headwaters.com.. 
Frank Sergeant, 809 W. San Antonio St., San Marcos, TX 

78666, E-mail: pygmy@pobox.com. 
Tilmann Reli, Germany, E-mail: tilmann.reh@hrz.uni- 

siegen.d400.de. Has many programs for CP/M+ and is active 

with Z180/280 ECB bus/Modular/Embedded computers. 

Microcontrollers (8051). 
Helmut Jungkunz, Munich, Germany, ZNODE #5 1 , 8N 1 , 300- 

14.4, +49.89.961 45 75. Email: hehnut.jungkunz@metronetde. 

USER GROUPS 

Connecticut CP/M Users Group, contact Stqjhen Griswold, 
PO Box 74, Canton CT 06019-0074, BBS: (203)665-1100. 
Sponsors Z-fests. 

SMUG, Sacramento Mcrocon^uter Users Group, has disbanded 
after all these years. 

CAPDUG: The Capital Area Public Domain Users Group, News- 
letter $20, Al Siegel Associates, Inc., PO Box 34667, Betherda 
MD 20827. BBS (301) 292-7955. 

NOVAOUG: The Northern Virginia Osborne Users Group, 
Newsletter $12, Robert L. Critics, 7512 Fairwood Lane, Falls 
Church, VA 22046. Info (703) 534-1186, BBS use 
CAPDUG's. 



The Windsor Bulletin Board Users' Group: England, Contact 
Rodney Hannis, 34 Falmouth Road, Reading, RG2 8QR, or 
Mark Minting, 94 Undley Common, Lakenheath, Brandon, 
Suffolk, IP27 9BZ, Phone 0842-860469 (also sells NZCOM/ 
Z3PLUS). 

NATGUG, the NaUonal TRS-80 Users Group, Roger Storrs, 
Oakfield Lodge, Ram Hill, Coalpit Heath, Bristol, BS17 2TY, 
UK. Tel: +44 (0)1454 772920. 

L J5.T.: Long Island Sinclair and Timex support group, contact 
Harvey Rait, 5 Peri Lane, Valley Stream, NY 11581. 

ADAM-Link User's Group, Salt Lake City, Utah, BBS: 
(801)484-5114. Supporting Coleco ADAM machines, with 
Newsletter/BBS. 

Adam International Media, Adam's House, 1829-1 County 
Road 130, Pearland, TX 77581-5040. Contact Terry Fowler 
for information. Web: "HTTP:// WWW.Flash.Net/~coleco" 

AUGER, Emerald Coast ADAM Users Group, PO Box 4934, 
Fort Walton Beach FL 32549-4934, (904)244-1516. Contact 
Norman J. Deere, treasurer and editor for pricing and newslet- 
ter information. 

MOAUG, Metro Orlando Adam Users Group, Contact James 
Poulin, 1146 Manatee Dr. Rockledge FL 32955, (407)631- 
0958. 

Metro Toronto Adam Group, Box 165, 260 Adelaide St. E., 
Toronto, ONT MSA INO, Canada, (416)424-1352. 

Omaha ADAM Users Club, Contact Norman R. Castro, 809 
W. 33rd Ave. Bellevue NE 68005, (402)291-4405. Suppose 
to be oldest ADAM group. 

Vancouver Island Senior ADAMphiles, AD VISA newsletter 
by David Cobley, 17-885 Berwick Rd. Qualicum Beach, B.C., 
Canada V9K 1N7, (604)752-1984. dcobley@qb.island.net 

Northern lUiana ADAMS User's Group, 9389 Bay Colony 
Dr. #3E, Des Plaines IL 60016, (708)296-0675. 

San Diego OS-9 Users Group, Contact Warren Hrach (619)221- 
8246, BBS: (619)224^878. 

The San Diego Computer Society (SDCS) is abroad spectrum 
organization that covers interests in diverse areas of software 
and hardware. It is an umbrella organization to various Spe- 
cial Interest Groups (SIGs). Voice information recordings are 
available at 619-549-3787. 

The Dina-SIG part of SDCS is primarily for Z-80 based com- 
puters from Altair to Zorba. The SIG sponsored BBS - the 
Elephant's Graveyard (619-571-0402) - is open to all callers 
who are interested in Z-80 and CP/M related machines and 
software. Contact Don Maslin, head of the Dina-SIG and the 
sysop of the BBS at 619-454-7392. Email: donm@cts.com. 

ACCESS, PO Box 1354, Sacramento, CA 95812, Contact Bob 
Drews (916)423-1573. Meets first Thurdays at SMUD 59Th 
St.(ed.bldg.). 
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Forth Interest Group, PO Box 2154, Oakland CA 94621 510- 

89-FORTH. International support of the Forth language, local 

chapters. 
The Pacific Northwest Heath Users Group, contact Jim Moore, 

1554 - 16th Avenue East, SeatUe, WA 98112-2807. Email: 

be483@scn.org. 

The SNO-KING Kaypro User Group, contact Donald Ander- 
son, 13227 2nd Ave South, Burien, WA 98168-2637. 

SeaFOG (Seattle FOG User's Group, Formerly Osborne Users 
Group) PO Box 12214, SeatUe, WA 98102-0214. 



OTHER PUBLICATIONS 

The Z-Letter - has ceased publication. 

The Analytical Engine, by the Computer History Association of 
California, 4159-C El Camino Way, Palo Alto, CA 94306- 
4010. Home page: http://www.chac.org/chac/ E-mail: 
engine@chac.org 

Z-100 UfeUne, Steven W. Vagts, 2409 Riddick Rd. Elizabeth 
City, NC 27909, (919)338-8302. Publication for Z-100 (an S- 
100 machine). 

The Staunch 8/89'er, Kirk L. Thompson editor, PO Box 548, 
West Branch lA 52358, (319)643-7136. $15/yr(US) publica- 
tion for H-8/89S. 

The SEBHC Journal, Leonard Geisler, 895 Starwick Dr., Ann 
Arbor MI 48105, (313)662-0750. Magazine of the Society of 
Eight-Bit Heath computerists, H-8 and H-89 support. 

Sanyo PC Hackers Newsletter, Victor R. Frank editor, 12450 
Skyline Blvd. Woodside, CA 94062-4541, (415)851-7031. 
Support for orphaned Sanyo computers and software. 

the world of 68' micros, by FARNA Systems, PO Box 321, 
Warner Robins, GA 31099-0321 . E-mail: dsrtfox@delphi.com. 
New magazine for support of old CoCo's and other 68xx(x) 
systems. 

Amstrad PCW SIG, newsletter by Al Warsh, 6889 Crest Av- 
enue, Riverside, CA 92503-1 162. $9 for 6 bi-monthly news- 
letters on Amstrad CP/M machines. 

Historically Brewed, A publication of the Historical Computer 
Society. Bimonthly at $18 a year. HCS, 2962 Park Street #1, 
Jacksonville, FL 32205. Editor David Greelish. Computer 
History and more. 

IQLR (International QL Report), contact Bob Dyl, 15 Kilburn 
Ct. Newport, RI 02840. Subscription is $20 per year. 
Email :IQLR@ nccnet.com. 

QL Hacker's Journal (QHJ), Timothy Swenson, 5615 Botkins 
Rd., Huber Heights, OH 45424, (513) 233-2178, sent mail & 
E-mail, swensotc@ss2.sews.wpafb.af.mil. Free to program- 
mers of QL's. 

Update Magazine, PO Box 1095, Peru, IN 46970, Subs $18 per 
year, supports Sinclair, Timex, and Cambridge computers. 
Emil: fdavis@holli.com. 



SUPPORT BUSINESSES 

Hal Bower writes, sells, and supports B/PBios for Ampro, 
SB180, and YASBEC. $69.95. Hal Bower, 7914 Redglobe 
Ct., Severn MD 21144-1048, (410)551-5922. 



Sydex, PO Box 5700, Eugene OR 97405, (541)683-6033. Sells 
several CP/M programs for use with PC Clones ('22Disk' 
format/copies CP/M disks using PC files system). 

Elliam Associates, PO Box 2664, Atascadero CA 93423, 
(805)466-8440. Sells CP/M user group disks and Amstrad 
PCW products. Email:?? 

Discus Distribution Services, Inc. sells CP/M for $ 1 50, CB ASIC 
$600. Fortran-77 $350, Pascal/MT+ $600. 8020 San Miguel 
Canyon Rd., Salinas CA 93907, (408)663-6966. 

Microcomputer Mail-Order Library of books, manuals, and 
periodicals in general and H/Zenith in particular. Borrow items 
for small fees. Contact Lee Hart, 4209 France Ave. North, 
Robbinsdale MN 55422, (612)533-3226. 

Star-K Software Systems Corp. PO Box 209, Mt. Kisco, NY 
10549, (914)241-0287, BBS: (914)241-3307. SK*DOS 6809/ 
68000 operating system and software. Some educational prod- 
ucts, call for catalog. 

Peripheral Technology, 1250 E. Piedmont Rd., Marietta, GA 
30067, (404)973-2 1 56. 6809/68000 single board system. 68K 
ISA bus compatible system. 

Hazelwood Computers, RR#1, Box 36, Hwy 94@BIuffton, 
Rhineland, MO 65069, (314)236-4372. Some SS-50 6809 
boards and new 68000 systems. 

AAA Chicago Computers, Jerry Koppel, (708)681-3782. SS- 
50 6809 boards and systems. Very United quanity, call for 
information. 

MicroSolutions Computer Products, 132 W. Lincoln Hwy, 
DeKalb, IL 60 1 1 5, (8 1 5)756-34 1 1 . UNIFORM Format-trans- 
lation, CompatiCard and UniDos products have been discon- 
tinued. Web page: http://www.micro-solutions.com. 

GIMIX/OS-9, GMX, 3223 Arnold Lane, Northbrook, IL 60062, 
(800)559-0909, (708)559-0909, FAX (708)559-0942. Repair 
and support of new and old 6800/6809/68K/SS-50 systems. 

n/SYSTEMS, Terry Hazen, 21460 Bear Creek Rd, Los Gatos 
CA 95030-9429, (408)354-7188, sells and supports UieMDISK 
add-on RAM disk for the Ampro LB. PCB $29, assembled 
PCB $129, includes driver software, manual. 

Corvatek, 561 N.W. Van Buren St. Corvallis OR 97330, 
(503)752-4833. PC style to serial keyboard adapter for Xerox, 
Kaypros, Franklin, Apples, $129. Other models supported. 

Morgan, Thielmann & Associates services NON-PC compat- 
ible computers including CP/M as well as clones. Call Jerry 
Davis for more information (408) 972-1965. 

Jim S. Thale Jr., 1150 Somerset Ave., Deerfield IL 60015- 
2944, (708)948-5731. Sells I/O board for YASBEC. Adds 
HD drives, 2 serial, 2 parallel ports. Partial kit $150, complete 
kit $210. 

Trio Company of Cheelctowaga, Ltd., PO Box 594, 
Cheektowaga NY 14225, (716)892-9630. SeUs CP/M (& PC) 
packages: InfoStar 1.5 ($160); SuperSort 1.6 ($130), and 
WordStar 4.0 ($130). 

Parts is Parts, Mike Zinkow, 137 Barkley Ave., Clifton NJ 
0701 1-3244, (201)340-7333. Supports Zenith Z-100 with parts 
and service. 

DYNACOMP, 178 Phillips Rd. Webster, NY 14580, (800)828- 
6772. Supplying versions of CP/M, TRS80, Apple, CoCo, 
Atari, PC/XT, software for older 8/16 bit systems. Call for 
older catalog. 
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• Z-Sys Comer - ZMATE MACRO usage 

• Moving Forth - Part 1 

• Center Fokl - IMSAI MPU-A 

• Developing Turnkey Forth Applications 

• Mr. Kaypro - Versions of Kaypros 

• DR S-100 - Vendors 

Issue Number 60: 

• Next Ten Years - Part II 

• Moving Forth Part II 
•Canter Fokl- IMSAI CPA 

• Four for Forth - Forth CPlTs 

• Debugging Forth 

• Z-Sys Comer - 8 years of Z-System 

• Mr. Kaypro - Turning a Kaypro II into a IV 

• DR S-100 -Letters 

Issue Number 61: 
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• Multiprocessing / 6809 part I 
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Issue Number 62: 
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• Center FoU - XEROX 820 
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• Moving Forth part III 

• Programming the 6526 CIA 
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Issue Number 63: 

• Z-Sys Comer - Faisafe Scripts in 4DOS 

• SCSI EPROM Programmer - part II 

• Center FoM- XEROX 820 

• DR S-100 - Disk Drives and BIOS code 

• Multiprocessing Part II 

• 6809 Operating Systems 

• IDE Drives Pat II 

Issue Number 64: 

• Z-Sys Comer - Failsafe Scripts in 4D0S II 

• Small-C - Review and comment 

• Center Fokl - last XEROX 820 

• DR S-100 - Disk Drives and BIOS - part II 

• Moving Forth Part IV 

• Small Systems - 6800^6809 Hbtoiy 

• Mr. Kaypro - Sign on and Clock Upgrade 

• IDE Drives - Part III 

Issue Number 65: 

• Small System Support - 68xx Serial Comm 

• Sinclair ZX81 - Letters and Books 

• Center Fold -ZX8Q/81 

• OR S-100 - Christmas letters 

• Real Computing - Linux and Linking 

• European Beat - AMSTRAD in Europe 

• PC/XT Comer - Day-OM Computing 

• Little Circuits - Fteset Cirouits 

• Levels of Forth - Selecting a Language 

Issue Number 66: 

• Z-System Comer - Failsafe Scripts in 4DOS 

• Real Computing - TCP/IP and OSI 

• Small System Support - "C and 68xx 

• Center Fokl - Advent Decoder Board 



• DR S-100 - Spring Letteis 

+ Connecting IDE Drives (IDE part IV) 

• PC/XT Comer- Day-Old Computing 

• Litlle Circuits - Battery Backup Ciicults 

• Multiprocessing Part III 

Issue Number 67: 

• European Beat - more AMSTRAD histoiy 

• Small System Support ■ 6800/09 programs 

• Center Fold - SS-50«S-30 

• DR S-100 - Trenton/Z-Fest & letters 

• Serial Kaypro Intenupts in Forth 

• Real Computing - Tiny-TCP and WIN 

• Little Circuits - Wire and Cable 

• Mcving Forth Part 5 

Issue Number 68: 

• Small System Support - L.anguages 

• Center Fokl - Pertec/Mits 4PI0 

• Z-System Comer II - Intro CP/M and Z-Sys 

• PC/XT Comer - A bit of eveiything - Part I 

• Little CirouKs - CMOS and RCs 

• Multiprocessing Forth Part 4 

• Mr. Kaypro - Notes, Repaiis, and Macros 

Issue Number 69: 

• Small System Support - 6809 ASM, Flex 

• Center Fokj- S-100 IDE 

• Z-System Comer II - Intro, part 2 

• Real Computing - Tiny-TCP 

• PC/XT Comer - Stepper Motora and Forth 
•DA S-100 -Mail Bag 

• Moving Forth Part 6 

• Mr. Kaypro ■ Advent Decoder Constmction 

Issue Number 70: 

• Small System Support - 6809 ASM 

• Center Fold - Jupiter ACE 

• Z-System Comer II - Intro part 3 

• PC/XT Corner - Stepper Motors & Forth 

• DR S-100 -Mail Bag 

• Multiprocessing Part 5 

• European Beat - 8-bit kJiot and AMSTRAD 

Issue Number 71: 

• Computing Hero of 1994 - David Jaffa 

• Small System Support - 6809 ASM 

• Center Fokl - Hayes 80-1 03A S-100 modem 

• Power Supply Basics 

• PC/XT Comer - Stepper Motors 

.f Connecting IDE Drives (5) - QIDE Preview 

• DR S-100 - Generic IDE and CompuPro 

• Moving Forth Part 7 

• Mr. Kaypro - ROM options 

• 8048 Emulator Part 1 

Issue Number 72: 

• Beginning PLD - good and bad 

• Small System Support - 'C and ASM 

• Center Foki - Rockwell R65F1 1 

• Playing With Micros - 5 to leam with 

• Real Computing - Languages 

• Small Tools Part 1 - Forth, 6SHC11 

• DR S-100 - CompuPro 8080/8086 

• Moving Forth Part 7.5 

• 8048 Emulator Part 2 

Issue Number 73: 

• $10 XT - what you can get at a swap meet 

• Small System Support - 'C and ASM 

• Center FOW-640K XT 



* IDE Part 6 
Real Computing - Linux 
Small Tools Part II - New Micros F68HC1 1 
DR. S-100 - Trenton and Letters 
PC/XT Comer - software quandaries 
8048 Emulator Part 3 

Issue Number 74: 



Antique or Junk - How to judge your system 

Small System Support - 'C and ASM 

Center Fold - S-100 Power Supply 

Real Computing - Linux and Minix 

AMSTRAD PCW Now 

DR S-100 -Madbag 

Mr. Kaypro - Adding Composite Monitois 

Palmtech CPUZ180 - Review 

Disk I/O in Forth 

Moving Forth part 8 

Issue Number 75: 



The European Beat - East German Z80 

Small System Support - 'C and ASM 

Center Fold - Standard Bus and I/O 

Moving Forth part 8 

Real Computing - Rick moved 

Embedded Control Using the STD Bus 

DR S-100 - MaHbag 

EPROM Simulator 

High-Speed Serial I/O for the Applicaid 

Disk I/O in Forth, PI. 2 

T9600 Souroe Code (Small Tools) 

Issue Number 76: 



Real Computing - Minix and more 

PC/XT Comer - Bank Switching/Supercharge 

The European Beat - 10 years for user group 

Altematives to the XT 

DR. S-100 - GIDE and the Jade Bus Probe 

Center Fold - JADE Bus Probe 

PC Time Clock - Improving Accuracy 

PC Security System - Home Security 

Snnall System Support - 'C and ASM 

Fk>ppy Disk Problems - design problems 

Issue Number 77: 



Mr. Kaypro - External Video 

Hands-on with PLCs 

Center Fold - CPU280 

The First TRS-80 

Program ThisI - the Z80 SIO 

Small System Support - Prime Numbers in C 

Issue Number 76: 



6502 DIY Board 

Program ThisI - 8051 Startup Code 

Center Fold - AMR 80552 

Simplex III - Homebuilt TTL CPU 

Real Computing - Small C, C-64, Win95 

Small System Support - C and Assembler 

Issue Number 79: 



PC serial port in Forth 
Program ThisI - AT Modem Commands 
Center Foki - P1 12 Z182 board 
Simplex III - HomebuiH TU CPU 
Real Computing - Real-time Control 
Small System Support - C and Assembler 
Embedded Oevekipment Choices 
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Regular Feature 

Editorial Comment 

Going Hi-Tech 



The Computer-' Conner 

By Bill Kibler 



Welcome back to TCJ! I say that only 
because time is moving on and each 
issue is now taking some time to hap- 
pen. Dave would love to move things 
faster than he is, but the rate of money 
coming into TCJ is rather slow. When 
I was editor, I would just dig deep into 
my pocket and find an extra thousand 
or so and keep on moving. Of course I 
never did get that money back and had 
to drop out as editor because of it. Dave 
however has no pockets to pull from 
and thus must print when he finally 
has the money. 

I would love to help out and have a few 
times, but my own expenses have 
grown and I must make up for three 
years of losses. That of course explains 
why I am working on UNIX systems 
and doing C. I have almost recovered 
from the loss of sleep, free time, and 
money, only to look back and wish I 
could have made it work. Our time as 
the magazine supporting collectors is 
still around the comer, but systems like 
NT have people considering the old al- 
ternatives. 

WINNT 

Needing to pay for food and such has 
caused me to do regular programming 
on UNIX platforms. We use Win95 
and WinNT platforms to run our tools 
on. These tools enable us to talk to the 
HP-Unix platforms and do our pro- 
gramming tasks. It gives me a chance 
to compare and understand better the 
advantages of simple and complex sys- 
tems. 

To show how much I have been con- 
verted to Unix, my fingers now work 
very automatically to move the cursor 
around in VI, the Unix editor. Vi is a 
little simple but very straight forward 
editor. On almost all platforms every 



Unix programmer or administrator 
must know how to use it. Some even 
love it, I am not there yet. It is how- 
ever some of these little Unix tools that 
can give you a good feeling about us- 
ing that platform. The tools usually 
work (hear that M/S), a manual is on- 
line, and when you usually have a 
problem, someone has already created 
a tools for you. It also explains why so 
many Unix tools are ending up on 
PC's. 

Now I have moved my own box at work 
from NT3.51 to NT4.0. I liked 3.51 
better, mostly for it's regular windows 
setup (like 3.1). The new win95 desk- 
top I find a drag, especially all the lay- 
ers one must go through to change 
something. That of course depends on 
if you are allowed to change them at 
all. They have changed many tool 
names, removed some, replaced others. 
I have tried to add a parallel port hard 
drive to the box several times now, all 
without success. It says it is there, 
works, is running, but I am unable to 
get a drive letter. 

Now under DOS I use the fdisk pro- 
gram to find out if I had a drive that 
was not setup correctly and thus was 
the reason it wasn't being seen. Fdisk 
is no where to be found in NT, nor can 
I find a way to test for an unformatted 
hard drive. It may be there, they just 
don't want you to find it without hav- 
ing gone to one of their special thou- 
sand dollar schools. 

At this point I say give me Linux or 
plain old DOS, even CP/M would be 
better than this nonsense. But I have 
one item to top even this mess. 

MMX 

Well Intel has their new CPU (the 



MMX or Pentium Pro, which is more 
Media Hype than horsepower upgrade) 
out and got one in the wings as well. I 
was reading an article in EETimes that 
caught my eye about the new CPU's. 
The units have power management 
built in, not to mention millions of 
transistors. This means they can idle 
back and save power when possible. 
These units also are run on anywhere 
from 1.8 to 3.5 volts depending on 
CPU speed, current needs, and tested 
performance at a given voltage. To do 
that a 4 or 5 bit signal is supplied to 
tell the power supply what voltage to 
select. 

Two things came to mind, one the 
added complexity and a problem talked 
about in the article. I felt the complex- 
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ity is partly to enable a better yield on 
the parts, as some chips were being 
chucked that fell outside some of the 
design parameters. However if the volt- 
age is kept a bit low or hi these once 
rejected chips will now work just fine, 
or at least they think so. I am not sure 
it's worth the extra hassles and pos- 
sible component costs and failures. 

Those cost and problems were of 
course the main concern. You see the 
part can drop current usage to around 
300 mills. But hit a key and zap your 
up to 12 Amps, yup 12 AMPS! That is 
a big change for any power supply, not 
to mention a whole lot of amps for a 
single CPU chip. I am not sure what 
gets me more, the switching from noth- 
ing to full power, or the fact that full 
power is 12 amps. You need some 
pretty big traces to handle those amps, 
not to mention the BIG spike such a 
current change will cause elsewhere in 
the system. Talk about a few design 
nightmares. 

The Real World 

Reading about all these changes makes 
me feel good about some of my other 
projects. I am still doing some 68HC1 1 
work on the side. It is mostly C and 
moving along rather smoothly. I got a 
good laugh out of an article in a C sup- 
port magazine. The writer was talking 
about doing embedded C++ and how 
a reduced set was needed. The fimny 
part was how he started the article. He 
mentioned how most embedded prod- 
ucts are too limited for C and espe- 
cially C++. 

This of course didn't stop him from 
continuing on talking about using C++ 
for embedded work. It is true a few or- 
ganizations are using C and C++ for 
embedded systems, it is just those em- 
bedded products are very expensive 
and usually have DOD stamped all 
over them. I still have problems with 
people who use the same term for mil- 
lion dollar projects and those in which 
the whole product will cost less then 
ten dollars. We need a new list of terms 
so people can understand there is a big 
difference between these two extremes 
of the concept. 

To me embedded systems generally 
have a cost of well under $100 and are 
not a major design concern or cost. 



Industrial real time control systems on 
the other hand are typically a major 
part of the cost. Maybe another idea is 
one that Dave keeps using, it's embed- 
ded if one person can do the design 
work, while it is an industrial control- 
ler if it takes a full staff to design and 
support the product. What terms might 
you think are best to separate these two 
veiy different fields of work. Send me 
an e-mail and I will list the ideas next 
time. 

Product Failure 

For those who wonder what has hap- 
pened with our own CDROM project, 
I can say it is moving along slowly. I 
now have up and running a CCS and 
a GodBout S-100 system with 8 inch 
disks. Between the two I hope to start 
going back through all my old disks 
and some recently acquired disks look- 
ing for items of interests. My main 
interest is source to BIOS and utilities. 
So far I have a good collection, but few 
have been moved to my hard drive for 
cataloging. 

Over the years I have heard many sto- 
ries about users turning on their old 
systems only to get nothing. Well it 
finally happened to me the other day. 
I hadn't used several units in about 
three or four months and moved them 
into position to help with the disk cata- 
loging. I tried three of the ZlOO's that 
had worked earlier and one was still 
connected to the 8 inch drives I was 
also going to use for copying. Well you 
can probably guess that not a one of 
the units would boot up. A couple had 
video problems, one just wouldn't boot 
no matter what. I finally gave up for 
now and dug out an older terminal and 
used that to test the S-100 systems 
with. 

My idea had been to use a Z-100 for a 
terminal with the occasional copy 
when one of the S-IOO systems 
wouldn't read the 8" disk. The Z-100 
also can copy from CP/M disk to 
MSDOS disk using one of their own 
utilities. Later checking showed the 
problem to be water damage that eaten 
away some of the traces and messed up 
one of the sockets. Where the water 
came from, I have no idea, but what a 
mess. I now have a better understand- 
ing of the frustration so many of you 
have told me about. However don't 



think using PC's will keep it from hap- 
pening. 

I got a panic call from an old friend 
who has some knowledge of comput- 
ers. His major skill set is two-way ra- 
dio which he did till he retired re- 
cently. He has played with computers 
some, but does not yet have the full 
grasp of what can go wrong. I have 
tried to help him resolve problems with 
windows which only frustrated him 
more as we often hit one wail or an- 
other. 

This problem had to do with adding a 
second printer, in this case one of the 
newer Epson. When attempting to send 
data to it, he got back a paper out mes- 
sage, no matter what. My friend had 
gotten a second parallel port card for 
his PC. When trying that card, noth- 
ing work, and thus a phone call to me. 
I re-checked all he did and drug the 
printer home where it tested just fine. 

I went back the next day and tried a 
few more things. First I checked the 
new parallel card and decided all the 
jumpers needed to be opposite from 
what the tech at the store told him. I 
used MSD and had a different, or OK 
status report on the two printer ports. 
Now that we knew the PC tech was 
wrong and one problems was conflict- 
ing port addresses, we tried the print- 
ers again. 

After a few minor tests, all started to 
work properly. The problem it seems 
starts with his old parallel port which 
gives a paper out error on the Epson 
no matter what, a mis-configured sec- 
ond board, and not enough experience 
to know that most computer store techs 
have trouble using the correct end of a 
screwdriver. I guess at this point I need 
to do my normal complaint and say 
how bad it is and all, but I did that far 
too many times already, so I will just 
let it pass. 

Till Next Time 

Speaking of passing, I just ran out of 
space, so hope your trials and tribula- 
tions are minor ones, and keep hack- 
ing. Bill. 
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TCJ CLASSIFIED ADS 



CLASSIFIED RATES! 
$5.00 PER LISTING! 

TCJ Classified ads are on a prepaid 
basis only. The cost is $5.00 per ad 
entry. Support wanted is a free service 
to subscribers who need to find old or 
missing documentation or software. 
Please limit your requests to one type of 
system. 

Commercial Advertising Rates: 



FOR SALE 



Size 


Once 


4+ 


Full 


$150 


$90 


1/2 Page 


$80 


$60 


1/3 Page 


$60 


$45 


1/4 Page 


$50 


$40 


Market Place 


$30 


$120/yr 


The Computer Journal 


P.O 


. Box 3900 


Citrus Heights, CA 95611-3900 


MAQAZINE$ ANP BOOKS 



Historically Brewed. The magazine of 
the Historical Computer Society. Read 
about the people and machines which 
changed our world. Buy, sell and trade 
"antique" computers. Subscriptions $14, 
or try an issue for $3. HCS, 3649 
Herschel St., Jacksonville, FL 32205. 

Start your own technical venture! Don 
Lancaster's newly updated INCRED- 
IBLE SECRET MONEY MACHINE 

n tells how. We now have autographed 
copies of the Guru's underground clas- 
sic for $21.50. Synergetics Press, Box 
809-J, Thatcher AZ, 85552. 

THE CASE AGAINST PATENTS 

Throughly tested and proven alterna- 
tives that work in the real world. $33.50. 
Synergetics Press, Box 809-J, Thatcher 
AZ, 85552. 



Remember, TCJ has all Back 
Issues available. See the 

Back Issues page for a list of 
the articles in each issue. 



TRS-80 - MODELS I, 2, HI, IV, 12, 
16, POCKET COMPUTER, AND 
COCO: Software, hardware, internal 
and external disk drives (360K/720K), 
hard drive's (both complete and bubles), 
replacement motherboards, floppy drive 
controllers, video boards, RS-232 
boards, keyboards, and more. Send 
4x10 SASE for list. 
Pete Bumgardner, Rt. 4 Box 36-H, Fort 
Payne, AL 35967-9408, (205)845-6581. 

FOR SALE: THE FORTH ARCHIVE 

from taygeta.com on CDROM is avail- 
able from Mountain View Press, Rt 2 
Box 429, La Honda, CA. 94020 
Ph: 415-747-0760 
ghaydon@forsythe.stanford.edu. 

SUPPORT / INFO WANTED 

Wanted: Intel SDK-85 documentation. 
This is a single board design kit with 
the 8085 CPU, includes a hex keypad 
and 7 segment LED readout. I have 
several of these units and would con- 
sider trading for interesting older com- 
puters. Ron Wintriss, 100 Highland 
Ave., Lisbon, NH 03585. 




Dave Baldwin 

Microprocessor, Digital, 

and Analog circuit design. 

PC layout and more. 

Voice (916) 722-3877 
Fax (916) 722-7480 
BBS (916) 722-5799 



Kibler Electronics 

Hardware Design & 
Software Programming 

8051, 6805, Z80, 68000, x86 

PLC Support and 

Documentation 

Bill Kibler 

P.O. Box 535 

Lincoln, CA 95648-0535 

(916) 645-1670 

e-mail: kibler@psyber.com 
htt p. //www. psyber.com/~kibler 
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Market Place 



TC^ T ^^^ Computer Journal 



This blank space is for 
Your ad. 



Advent Kaypro Upgrades 



TurboROM. Allows flexible 

configuration of your entire 

system, read/write additional 

formats and more, only $35. 

Replacement Floppy drives and 
Hard Drive Conversion Kits. Call 
or write for availability & pricing. 



r/ie Computer Journal 

P.O. Box 3900 

Citrus Heights, CA 95611-3900 

(916) 722-4970 

Fax (916) 722-7480 



TCJ MARKET PLACE 

Advertising for small business 

First Insertion: $30 

Reinsertion: $25 

Full Six issues $120 

Rates include typesetting. 

Payment must accompany order. 

VISA, MasterCard, Diner's Club, 

Carte Blanche accepted. Checks, 

money orders must be US funds. 

Resetting of ad consitutes a new 

advertisement at first time 

insertion rates. Mail ad or 

contact 

The Computer Journal 

P.O. Box 3900 

Citrus Heights, CA 95611-3900 

(916) 722-4970 

Fax (916) 722-7480 



CP/M SOFTWARE 
1 00 page Public Domain Cata- 
log, $8.50 plus $1 .50 shipping 
and handling. New CP/M 2.2 
manual $19.95 plus shipping. 
Also MS-DOS software. Disic 
Copying including AMSTRAD. 
Send self addressed, stamped 
envelope for free Flyer, Cata- 
log $1.00. 

Elliam Associates 

Box 2664 

Atascadero, CA 93423 

805-466-8440 



VERSATILE 80C32 AND 68HC11 
SINGLE BOARD COMPUTERS 



The DC8032-1 indudM lie following: 

• It.OSt lylH2 80C32 ixoMMW. 

• 32K of EPROM. 

• 4 diffwwit momay naps. 

• Exiondod BASIC-52 wilti 28 addilional conmands. 
Ttw DC681 1-1 includes he following: 
•8MH2MC68HC11piooessor. 

• 32K of EPROtil jump* selecUMe as 2 t6K Eproms. 

• M6ASIC11 wiUi custom analog and digital I/O oommands. 
All units indude the following standaf d laatuies: 

• 32K of battery-backed RAIil. 

• Real tme dock. 

• e-dunnel/8-bit fJO. 

• Centronics parallel printer port. 

• 24-bils of digital UO. 

• Watch dog timer. 

• 4 X 6 inch board size. 

• Operates on a single t to 12 volt DC power supply. 

• 40-pin expansion connector. 

• RS-232 port. 

• 30 day money back guarantee. 

• One year parts and labor warranty. 

All unit come with a 9 volt DC wall cube, serial cable, users manual, 
and OC.TERIkl terminal software. A utility if sk of shareware and 
freeware is also induded at no charge. 



0. C. MICROS 
1S43 Sumner Ct. 
La* Crucaa, Nfyi M001 
Ph. (SOS) S24-4029 



(140.00 kit or assembled and 

tested. Add $5.00 shipping 

and handling plus $5.00 tor 

COD 



VINTAGE COMPUTERS 

IBM Compatibles 

Tested - Used Parts for 

PC/XT AT PS/2 

Working systems from $50 

All parts including 

cases monitors floppies 

hard drives MFM RLL IDE 

Technical Specs 

Send 5x7 SASE to: 

Vintage Computers 

Paul Lawson 

1673 Litchfield Turnpike 

Woodbridge, CT 06525 

or call for a faxed list 

203-389-0104 



THE FORTH SOURCE 
Hardware & Software 

MOUNTAIN VIEW 
PRESS 

Glen B. Haydon, M.D. 

Route 2 Box 429 
La Honda, CA 94020 

(415) 747-0760 

http://www.taygeta.com/Jfar/mvp.html 



MORE POWER! 

68HC11,80C51&80C166 



More iVIicrocontrollers. 
Faster Hardware. 
Faster Software. 
IVIore Productive. 
IVIore Tools and Utilities. 

Low cost SBC's from $84. Get it 

done today! Not next month. 

For brochure or applications: 

AM Research 

P.O. Box 43 

Loomis, CA 95650-9701 

1(800)949-8051 

http://www.AMResearch.com 



$79 



95 



8K EEPROM for More 
Program Space! 

SER-eC,Op«ai>deK 
SwKIEEraOMtlO 



68HC11 

single Board 
Computer 

SBC-8K 

Snail size, 3 J'xJ.fi* 
U>w Power, <60 ma 
8192 Bytes EEPROM 
25< Bytes RAJVl 
DB-9 RS-232 
24-TTHIOBIts 
S-AfD Inputs 
Power Reset Circuit 
SMhzClock 
Log Data wHh SER-tC 



A Complats eaHCII Dsvalopmant System. 

Nsw *CodeLoad+ 2.0" and Sample Programs. 

No EPROMs or EPROM Programmers! 

500 Page* of Manuals, 3 J" UUllty Disk. 




LDG Electronics 

1445 Parran Road voice /f» 

St Leonard, MD 20685 410-586-2177 



